CVE-2022-48902

一、漏洞信息
 漏洞编号：[CVE-2022-48902](https://nvd.nist.gov/vuln/detail/CVE-2022-48902)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we re operating on annon-uptodate page.  Our overnight tests caught this warning earlier thisweek  WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014  Workqueue: btrfs-cache btrfs_work_helper  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0  Call Trace:   extent_buffer_test_bit+0x3f/0x70   free_space_test_bit+0xa6/0xc0   load_free_space_tree+0x1f6/0x470   caching_thread+0x454/0x630   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? lock_release+0x1f0/0x2d0   btrfs_work_helper+0xf2/0x3e0   ? lock_release+0x1f0/0x2d0   ? finish_task_switch.isra.0+0xf9/0x3a0   process_one_work+0x26d/0x580   ? process_one_work+0x580/0x580   worker_thread+0x55/0x3b0   ? process_one_work+0x580/0x580   kthread+0xf0/0x120   ? kthread_complete_and_exit+0x20/0x20   ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ( btrfs: clear extent bufferuptodate when we fail to write it ), however all that fix did was keepus from finding extent buffers after a failed writeout.  It didn t keepus from continuing to use a buffer that we already had found.In this case we re searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing.  After the switch we can look up an extentbuffer that hasn t been written yet and start processing that blockgroup.  Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we re protected by the tree lock to a certain degree here.  Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write.  However thisisn t necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon t save us here.  We ll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we ve  read  a block butit s not marked Uptodate.  On read we ClearPageError(), so if we re!Uptodate and !Error we know we didn t do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we re using it, and we ll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we re messing with it.
 漏洞公开时间：2024-08-22 10:15:04
 漏洞创建时间：2024-08-22 12:12:57
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2022-48902
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48902 | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2022-48902 | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| suse_bugzilla | https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| suse_bugzilla | https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| suse_bugzilla | https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-48902.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1229609 |
| ubuntu | https://www.cve.org/CVERecord?id=CVE-2022-48902 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://git.kernel.org/linus/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 (5.17-rc7) | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://nvd.nist.gov/vuln/detail/CVE-2022-48902 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://launchpad.net/bugs/cve/CVE-2022-48902 | https://ubuntu.com/security/CVE-2022-48902 |
| ubuntu | https://security-tracker.debian.org/tracker/CVE-2022-48902 | https://ubuntu.com/security/CVE-2022-48902 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2022-48902 |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 |  | nvd |
|  |  | https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 |  | nvd |
|  |  | https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 |  | nvd |
| linux |  | https://git.kernel.org/linus/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we re operating on annon-uptodate page.  Our overnight tests caught this warning earlier thisweek  WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014  Workqueue: btrfs-cache btrfs_work_helper  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0  Call Trace:   extent_buffer_test_bit+0x3f/0x70   free_space_test_bit+0xa6/0xc0   load_free_space_tree+0x1f6/0x470   caching_thread+0x454/0x630   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? lock_release+0x1f0/0x2d0   btrfs_work_helper+0xf2/0x3e0   ? lock_release+0x1f0/0x2d0   ? finish_task_switch.isra.0+0xf9/0x3a0   process_one_work+0x26d/0x580   ? process_one_work+0x580/0x580   worker_thread+0x55/0x3b0   ? process_one_work+0x580/0x580   kthread+0xf0/0x120   ? kthread_complete_and_exit+0x20/0x20   ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ( btrfs: clear extent bufferuptodate when we fail to write it ), however all that fix did was keepus from finding extent buffers after a failed writeout.  It didn t keepus from continuing to use a buffer that we already had found.In this case we re searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing.  After the switch we can look up an extentbuffer that hasn t been written yet and start processing that blockgroup.  Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we re protected by the tree lock to a certain degree here.  Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write.  However thisisn t necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon t save us here.  We ll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we ve  read  a block butit s not marked Uptodate.  On read we ClearPageError(), so if we re!Uptodate and !Error we know we didn t do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we re using it, and we ll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we re messing with it.
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP3(5.10.0):受影响
3.openEuler-22.03-LTS-SP4(5.10.0):受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS(6.6.0):不受影响
6.openEuler-24.03-LTS-Next(6.6.0):不受影响
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP3(5.10.0):否
3.master(6.6.0):否
4.openEuler-24.03-LTS(6.6.0):否
5.openEuler-24.03-LTS-Next(6.6.0):否
6.openEuler-22.03-LTS-SP4(5.10.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否

原因说明：
  1.openEuler-20.03-LTS-SP4(4.19.90):不修复-超出修复范围
2.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
3.openEuler-22.03-LTS-SP4(5.10.0):不修复-超出修复范围
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
6.openEuler-24.03-LTS(6.6.0):不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响-漏洞代码不存在

Hi openeuler-ci-bot, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers.

@yangyingliang ,@jiaoff ,@guohaocs2c ,@hanjun-guo ,@woqidaideshi ,@newbeats ,@zhangyi089 ,@colyli ,@thundertown ,@htforge ,@chiqijun ,@lengchao ,@zhujianwei001 ,@kylin-mayukun ,@wangxiongfeng ,@wkfxxx ,@SuperSix173 ,@jentlestea ,@oskernel0719 ,@gasonchen 
**issue处理注意事项:** 
**1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;**
**2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;**
**3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否))不能省略,省略后cve-manager将无法正常解析填写内容.**
************************************************************************
影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响): 
1.master(6.1.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):

修复是否涉及abi变化(是/否)：
1.master(6.1.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):

-----------------------------------------------------------------------
issue处理具体操作请参考: 
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://gitee.com/help/articles/4142

参考网址	关联pr	状态	补丁链接
https://nvd.nist.gov/vuln/detail/CVE-2022-48902	None	None	https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06
https://ubuntu.com/security/CVE-2022-48902	None	None	https://discourse.ubuntu.com/c/ubuntu-pro
https://www.opencve.io/cve/CVE-2022-48902	None	None	https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2022-48902
https://security-tracker.debian.org/tracker/CVE-2022-48902

说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用CVE补丁工具。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

CVE-2022-48902

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not WARN_ON() if we have PageError set

Whenever we do any extent buffer operations we call
assert_eb_page_uptodate() to complain loudly if we're operating on an
non-uptodate page.  Our overnight tests caught this warning earlier this
week

WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50
  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: btrfs-cache btrfs_work_helper
  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50
  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246
  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000
  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0
  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000
  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1
  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000
  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0
  Call Trace:

extent_buffer_test_bit+0x3f/0x70
   free_space_test_bit+0xa6/0xc0
   load_free_space_tree+0x1f6/0x470
   caching_thread+0x454/0x630
   ? rcu_read_lock_sched_held+0x12/0x60
   ? rcu_read_lock_sched_held+0x12/0x60
   ? rcu_read_lock_sched_held+0x12/0x60
   ? lock_release+0x1f0/0x2d0
   btrfs_work_helper+0xf2/0x3e0
   ? lock_release+0x1f0/0x2d0
   ? finish_task_switch.isra.0+0xf9/0x3a0
   process_one_work+0x26d/0x580
   ? process_one_work+0x580/0x580
   worker_thread+0x55/0x3b0
   ? process_one_work+0x580/0x580
   kthread+0xf0/0x120
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork+0x1f/0x30

This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer
uptodate when we fail to write it"), however all that fix did was keep
us from finding extent buffers after a failed writeout.  It didn't keep
us from continuing to use a buffer that we already had found.

In this case we're searching the commit root to cache the block group,
so we can start committing the transaction and switch the commit root
and then start writing.  After the switch we can look up an extent
buffer that hasn't been written yet and start processing that block
group.  Then we fail to write that block out and clear Uptodate on the
page, and then we start spewing these errors.

Normally we're protected by the tree lock to a certain degree here.  If
we read a block we have that block read locked, and we block the writer
from locking the block before we submit it for the write.  However this
isn't necessarily fool proof because the read could happen before we do
the submit_bio and after we locked and unlocked the extent buffer.

Also in this particular case we have path->skip_locking set, so that
won't save us here.  We'll simply get a block that was valid when we
read it, but became invalid while we were using it.

What we really want is to catch the case where we've "read" a block but
it's not marked Uptodate.  On read we ClearPageError(), so if we're
!Uptodate and !Error we know we didn't do the right thing for reading
the page.

Fix this by checking !Uptodate && !Error, this way we will not complain
if our buffer gets invalidated while we're using it, and we'll maintain
the spirit of the check which is to make sure we have a fully in-cache
block while we're messing with it.

openEuler评分:(评分和向量)
3.9
AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:不受影响
3.openEuler-22.03-LTS-SP3:不受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:不受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

@ 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 需分析 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page.  Our overnight tests caught this warning earlier thisweek  WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014  Workqueue: btrfs-cache btrfs_work_helper  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0  Call Trace:   extent_buffer_test_bit+0x3f/0x70   free_space_test_bit+0xa6/0xc0   load_free_space_tree+0x1f6/0x470   caching_thread+0x454/0x630   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? rcu_read_lock_sched_held+0x12/0x60   ? lock_release+0x1f0/0x2d0   btrfs_work_helper+0xf2/0x3e0   ? lock_release+0x1f0/0x2d0   ? finish_task_switch.isra.0+0xf9/0x3a0   process_one_work+0x26d/0x580   ? process_one_work+0x580/0x580   worker_thread+0x55/0x3b0   ? process_one_work+0x580/0x580   kthread+0xf0/0x120   ? kthread_complete_and_exit+0x20/0x20   ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout.  It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing.  After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup.  Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here.  Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write.  However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here.  We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate.  On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.|
|已分析|2.openEulerScore|3.9|
|已分析|3.openEulerVector|AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L|
|已分析|4.受影响版本排查|openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP1:不受影响,openEuler-22.03-LTS-SP3:不受影响,openEuler-22.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.修复是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**