CVE-2024-44972

一、漏洞信息
 漏洞编号：[CVE-2024-44972](https://nvd.nist.gov/vuln/detail/CVE-2024-44972)
 漏洞归属组件：[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 clear page dirty inside extent_write_locked_range()[BUG]For subpage + zoned case, the following workload can lead to rsv dataleak at unmount time:  # mkfs.btrfs -f -s 4k $dev  # mount $dev $mnt  # fsstress -w -n 8 -d $mnt -s 1709539240  0/0: fiemap - no filename  0/1: copyrange read - no filename  0/2: write - no filename  0/3: rename - no source filename  0/4: creat f0 x:0 0 0  0/4: creat add id=0,parent=-1  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0  # umount $mntThe dmesg includes the following rsv leak detection warning (all calltrace skipped):  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6  ------------[ cut here ]------------  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): space_info DATA has 268218368 free, is not full  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0  BTRFS info (device sda): global_block_rsv: size 0 reserved 0  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0  ------------[ cut here ]------------  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760  BTRFS info (device sda): global_block_rsv: size 0 reserved 0  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0Above $dev is a tcmu-runner emulated zoned HDD, which has a max zoneappend size of 64K, and the system has 64K page size.[CAUSE]I have added several trace_printk() to show the events (header skipped):  > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688  > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288  > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536  > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864The above lines show our buffered write has dirtied 3 pages of inode259 of root 5:  704K             768K              832K              896K  I           |////I/////////////////I///////////|     I              756K                               868K  |///| is the dirtied range using subpage bitmaps. and  I  is the page  boundary.  Meanwhile all three pages (704K, 768K, 832K) have their PageDirty  flag set.  > btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400Then direct IO writ---truncated---
 漏洞公开时间：2024-09-05 03:15:31
 漏洞创建时间：2024-09-27 02:08:13
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-44972
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-44972 | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-44972 | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-44972.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2309803 | https://bugzilla.suse.com/show_bug.cgi?id=1230212 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024090457-CVE-2024-44972-23b5@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2309803 |
| ubuntu | https://www.cve.org/CVERecord?id=CVE-2024-44972 | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://git.kernel.org/linus/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 (6.11-rc1) | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://nvd.nist.gov/vuln/detail/CVE-2024-44972 | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://launchpad.net/bugs/cve/CVE-2024-44972 | https://ubuntu.com/security/CVE-2024-44972 |
| ubuntu | https://security-tracker.debian.org/tracker/CVE-2024-44972 | https://ubuntu.com/security/CVE-2024-44972 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-44972 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2024-44972 |
| mageia |  | http://advisories.mageia.org/MGASA-2024-0309.html |

</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/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 |  | nvd |
|  |  | https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 |  | nvd |
|  |  | https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f |  | nvd |
| linux |  | https://git.kernel.org/linus/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
                                    Reserved.                 
 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-24.03-LTS(6.6.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.master(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(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-22.03-LTS-SP4(5.10.0):否

原因说明：
  1.master(6.6.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):

@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.6.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.6.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

<table><tr><th white-space: nowrap;>参考网址</th> <th white-space: nowrap;>关联pr</th> <th white-space: nowrap;>状态</th> <th white-space: nowrap;>补丁链接</th></tr><tr><td rowspan="1">https://nvd.nist.gov/vuln/detail/CVE-2024-44972</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0>https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0</a><br /><a href=https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f>https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f</a><br /><a href=https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368>https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368</a></td></tr><tr><td rowspan="1">https://ubuntu.com/security/CVE-2024-44972</td><td>None</td><td>None</td><td><a href=https://discourse.ubuntu.com/c/ubuntu-pro>https://discourse.ubuntu.com/c/ubuntu-pro</a></td></tr><tr><td rowspan="1">https://www.opencve.io/cve/CVE-2024-44972</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0>https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0</a><br /><a href=https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f>https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f</a><br /><a href=https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368>https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368</a></td></tr><tr><td>https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-44972</td><td></td><td></td><td></td></tr><tr><td rowspan="1">https://security-tracker.debian.org/tracker/CVE-2024-44972</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/linus/97713b1a2ced1e4a2a6c40045903797ebd44d7e0>https://git.kernel.org/linus/97713b1a2ced1e4a2a6c40045903797ebd44d7e0</a></td></tr></table>

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

CVE-2024-44972

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

btrfs: do not clear page dirty inside extent_write_locked_range()

[BUG]
For subpage + zoned case, the following workload can lead to rsv data
leak at unmount time:

# mkfs.btrfs -f -s 4k $dev
  # mount $dev $mnt
  # fsstress -w -n 8 -d $mnt -s 1709539240
  0/0: fiemap - no filename
  0/1: copyrange read - no filename
  0/2: write - no filename
  0/3: rename - no source filename
  0/4: creat f0 x:0 0 0
  0/4: creat add id=0,parent=-1
  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0
  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1
  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()
  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0
  # umount $mnt

The dmesg includes the following rsv leak detection warning (all call
trace skipped):

------------[ cut here ]------------
  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]
  ---[ end trace 0000000000000000 ]---
  ------------[ cut here ]------------
  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]
  ---[ end trace 0000000000000000 ]---
  ------------[ cut here ]------------
  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]
  ---[ end trace 0000000000000000 ]---
  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6
  ------------[ cut here ]------------
  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]
  ---[ end trace 0000000000000000 ]---
  BTRFS info (device sda): space_info DATA has 268218368 free, is not full
  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0
  BTRFS info (device sda): global_block_rsv: size 0 reserved 0
  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0
  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0
  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0
  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0
  ------------[ cut here ]------------
  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]
  ---[ end trace 0000000000000000 ]---
  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full
  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760
  BTRFS info (device sda): global_block_rsv: size 0 reserved 0
  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0
  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0
  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0
  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0

Above $dev is a tcmu-runner emulated zoned HDD, which has a max zone
append size of 64K, and the system has 64K page size.

[CAUSE]
I have added several trace_printk() to show the events (header skipped):

&gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864

The above lines show our buffered write has dirtied 3 pages of inode
259 of root 5:

704K             768K              832K              896K
  I           |////I/////////////////I///////////|     I
              756K                               868K

|///| is the dirtied range using subpage bitmaps. and &#39;I&#39; is the page
  boundary.

Meanwhile all three pages (704K, 768K, 832K) have their PageDirty
  flag set.

&gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400

Then direct IO write starts, since the range [680K, 780K) covers the
beginning part of the above dirty range, we need to writeback the
two pages at 704K and 768K.

&gt; cow_file_range: r/i=5/259 add ordered extent filepos=774144 len=65536
  &gt; extent_write_locked_range: r/i=5/259 locked page=720896 start=774144 len=65536

Now the above 2 lines show that we&#39;re writing back for dirty range
[756K, 756K + 64K).
We only writeback 64K because the zoned device has max zone append size
as 64K.

&gt; extent_write_locked_range: r/i=5/259 clear dirty for page=786432

!!! The above line shows the root cause. !!!

We&#39;re calling clear_page_dirty_for_io() inside extent_write_locked_range(),
for the page 768K.
This is because extent_write_locked_range() can go beyond the current
locked page, here we hit the page at 768K and clear its page dirt.

In fact this would lead to the desync between subpage dirty and page
dirty flags.  We have the page dirty flag cleared, but the subpage range
[820K, 832K) is still dirty.

After the writeback of range [756K, 820K), the dirty flags look like
this, as page 768K no longer has dirty flag set.

704K             768K              832K              896K
  I                I      |          I/////////////|   I
                          820K                     868K

This means we will no longer writeback range [820K, 832K), thus the
reserved data/metadata space would never be properly released.

&gt; extent_write_cache_pages: r/i=5/259 skip non-dirty folio=786432

Now even though we try to start writeback for page 768K, since the
page is not dirty, we completely skip it at extent_write_cache_pages()
time.

&gt; btrfs_direct_write: r/i=5/259 dio done filepos=696320 len=0

Now the direct IO finished.

&gt; cow_file_range: r/i=5/259 add ordered extent filepos=851968 len=36864
  &gt; extent_write_locked_range: r/i=5/259 locked page=851968 start=851968 len=36864

Now we writeback the remaining dirty range, which is [832K, 868K).
Causing the range [820K, 832K) never to be submitted, thus leaking the
reserved space.

This bug only affects subpage and zoned case.  For non-subpage and zoned
case, we have exactly one sector for each page, thus no such partial dirty
cases.

For subpage and non-zoned case, we never go into run_delalloc_cow(), and
normally all the dirty subpage ranges would be properly submitted inside
__extent_writepage_io().

[FIX]
Just do not clear the page dirty at all inside extent_write_locked_range().
As __extent_writepage_io() would do a more accurate, subpage compatible
clear for page and subpage dirty flags anyway.

Now the correct trace would look like this:

&gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536
  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864

The page dirty part is still the same 3 pages.

&gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400
  &gt; cow_file_range: r/i=5/259 add ordered extent filepos=774144 len=65536
  &gt; extent_write_locked_range: r/i=5/259 locked page=720896 start=774144 len=65536

And the writeback for the first 64K is still correct.

&gt; cow_file_range: r/i=5/259 add ordered extent filepos=839680 len=49152
  &gt; extent_write_locked_range: r/i=5/259 locked page=786432 start=839680 len=49152

Now with the fix, we can properly writeback the range [820K, 832K), and
properly release the reserved data/metadata space.

The Linux kernel CVE team has assigned CVE-2024-44972 to this issue.

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 clear page dirty inside extent_write_locked_range()[BUG]For subpage + zoned case, the following workload can lead to rsv dataleak at unmount time:  # mkfs.btrfs -f -s 4k $dev  # mount $dev $mnt  # fsstress -w -n 8 -d $mnt -s 1709539240  0/0: fiemap - no filename  0/1: copyrange read - no filename  0/2: write - no filename  0/3: rename - no source filename  0/4: creat f0 x:0 0 0  0/4: creat add id=0,parent=-1  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0  # umount $mntThe dmesg includes the following rsv leak detection warning (all calltrace skipped):  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6  ------------[ cut here ]------------  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): space_info DATA has 268218368 free, is not full  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0  BTRFS info (device sda): global_block_rsv: size 0 reserved 0  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0  ------------[ cut here ]------------  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]  ---[ end trace 0000000000000000 ]---  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760  BTRFS info (device sda): global_block_rsv: size 0 reserved 0  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0Above $dev is a tcmu-runner emulated zoned HDD, which has a max zoneappend size of 64K, and the system has 64K page size.[CAUSE]I have added several trace_printk() to show the events (header skipped):  &gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864The above lines show our buffered write has dirtied 3 pages of inode259 of root 5:  704K             768K              832K              896K  I           |////I/////////////////I///////////|     I              756K                               868K  |///| is the dirtied range using subpage bitmaps. and &#39;I&#39; is the page  boundary.  Meanwhile all three pages (704K, 768K, 832K) have their PageDirty  flag set.  &gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400Then direct IO write starts, since the range [680K, 780K) covers thebeginning part of the above dirty range, we need to writeback thetwo pages at 704K and 768K.  &gt; cow_file_range: r/i=5/259 add ordered extent filepos=774144 len=65536  &gt; extent_write_locked_range: r/i=5/259 locked page=720896 start=774144 len=65536Now the above 2 lines show that we&#39;re writing back for dirty range[756K, 756K + 64K).We only writeback 64K because the zoned device has max zone append sizeas 64K.  &gt; extent_write_locked_range: r/i=5/259 clear dirty for page=786432!!! The above line shows the root cause. !!!We&#39;re calling clear_page_dirty_for_io() inside extent_write_locked_range(),for the page 768K.This is because extent_write_locked_range() can go beyond the currentlocked page, here we hit the page at 768K and clear its page dirt.In fact this would lead to the desync between subpage dirty and pagedirty flags.  We have the page dirty flag cleared, but the subpage range[820K, 832K) is still dirty.After the writeback of range [756K, 820K), the dirty flags look likethis, as page 768K no longer has dirty flag set.  704K             768K              832K              896K  I                I      |          I/////////////|   I                          820K                     868KThis means we will no longer writeback range [820K, 832K), thus thereserved data/metadata space would never be properly released.  &gt; extent_write_cache_pages: r/i=5/259 skip non-dirty folio=786432Now even though we try to start writeback for page 768K, since thepage is not dirty, we completely skip it at extent_write_cache_pages()time.  &gt; btrfs_direct_write: r/i=5/259 dio done filepos=696320 len=0Now the direct IO finished.  &gt; cow_file_range: r/i=5/259 add ordered extent filepos=851968 len=36864  &gt; extent_write_locked_range: r/i=5/259 locked page=851968 start=851968 len=36864Now we writeback the remaining dirty range, which is [832K, 868K).Causing the range [820K, 832K) never to be submitted, thus leaking thereserved space.This bug only affects subpage and zoned case.  For non-subpage and zonedcase, we have exactly one sector for each page, thus no such partial dirtycases.For subpage and non-zoned case, we never go into run_delalloc_cow(), andnormally all the dirty subpage ranges would be properly submitted inside__extent_writepage_io().[FIX]Just do not clear the page dirty at all inside extent_write_locked_range().As __extent_writepage_io() would do a more accurate, subpage compatibleclear for page and subpage dirty flags anyway.Now the correct trace would look like this:  &gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536  &gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864The page dirty part is still the same 3 pages.  &gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400  &gt; cow_file_range: r/i=5/259 add ordered extent filepos=774144 len=65536  &gt; extent_write_locked_range: r/i=5/259 locked page=720896 start=774144 len=65536And the writeback for the first 64K is still correct.  &gt; cow_file_range: r/i=5/259 add ordered extent filepos=839680 len=49152  &gt; extent_write_locked_range: r/i=5/259 locked page=786432 start=839680 len=49152Now with the fix, we can properly writeback the range [820K, 832K), andproperly release the reserved data/metadata space.The Linux kernel CVE team has assigned CVE-2024-44972 to this issue.|
|已分析|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:受影响,openEuler-24.03-LTS:受影响,master:不受影响,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:否|

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