CVE-2025-39779

一、漏洞信息
 漏洞编号：[CVE-2025-39779](https://nvd.nist.gov/vuln/detail/CVE-2025-39779)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：N/A None
  Vector：CVSS：3.0/
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated.  assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899  ------------[ cut here ]------------  kernel BUG at fs/btrfs/zoned.c:1899!  Oops: invalid opcode: 0000 [#1] SMP NOPTI  CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary)  Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021  Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]  RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs]  RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246  RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000  RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff  RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8  R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00  R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680  FS:  0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0  Call Trace:   <TASK>   ? srso_return_thunk+0x5/0x5f   btrfs_finish_ordered_io+0x4a/0x60 [btrfs]   btrfs_work_helper+0xf9/0x490 [btrfs]   process_one_work+0x204/0x590   ? srso_return_thunk+0x5/0x5f   worker_thread+0x1d6/0x3d0   ? __pfx_worker_thread+0x10/0x10   kthread+0x118/0x230   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x205/0x260   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1a/0x30   </TASK>Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let s call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state.   0     4K    8K   |/////|/////|  (flag: DIRTY, tag: DIRTY)   <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages().   0     4K    8K   |/////|/////|  (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X s TOWRITE tag.   0     4K    8K   |     |/////|  (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won t see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.
 漏洞公开时间：2025-09-12 01:15:43
 漏洞创建时间：2025-09-12 02:05:11
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2025-39779
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
|  | https://bugzilla.redhat.com/show_bug.cgi?id=2394616 |  |
|  | https://www.cve.org/CVERecord?id=CVE-2025-39779 |  |
|  | https://docs.bell-sw.com/security/cves/CVE-2025-39779 |  |
|  | https://lore.kernel.org/linux-cve-announce/2025091148-CVE-2025-39779-7d77@gregkh/T |  |
|  | https://git.kernel.org/stable/c/bce7a5c77a1e7a759e227b7713dde18c52da4759 |  |
|  | https://ubuntu.com/security/CVE-2025-39779 |  |
|  | https://lore.kernel.org/linux-cve-announce/2025091148-CVE-2025-39779-7d77@gregkh/T/#u |  |
|  | https://git.kernel.org/stable/c/3d61136945a7008fc90d013c3c67007ce0c96131 |  |
|  | https://git.kernel.org/stable/c/b1511360c8ac882b0c52caa263620538e8d73220 |  |
|  | https://security-tracker.debian.org/tracker/CVE-2025-39779 |  |
|  | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-39779 |  |
|  | https://advisory.echohq.com/cve/CVE-2025-39779 |  |
|  | https://linux.oracle.com/cve/CVE-2025-39779.html |  |
|  | https://linux.oracle.com/errata/ELSA-2025-25754.html |  |
|  | https://git.kernel.org/linus/b1511360c8ac882b0c52caa263620538e8d73220 |  |
|  | https://nvd.nist.gov/vuln/detail/CVE-2025-39779 |  |

</details>

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

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/stable/c/bce7a5c77a1e7a759e227b7713dde18c52da4759 |  | cvelistv5 |
|  |  | https://git.kernel.org/stable/c/3d61136945a7008fc90d013c3c67007ce0c96131 |  | cvelistv5 |
|  |  | https://git.kernel.org/stable/c/b1511360c8ac882b0c52caa263620538e8d73220 |  | cvelistv5 |
|  |  | https://git.kernel.org/linus/b1511360c8ac882b0c52caa263620538e8d73220 |  | osv |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated.  assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899  ------------[ cut here ]------------  kernel BUG at fs/btrfs/zoned.c:1899!  Oops: invalid opcode: 0000 [#1] SMP NOPTI  CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary)  Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021  Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]  RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs]  RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246  RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000  RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff  RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8  R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00  R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680  FS:  0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0  Call Trace:   <TASK>   ? srso_return_thunk+0x5/0x5f   btrfs_finish_ordered_io+0x4a/0x60 [btrfs]   btrfs_work_helper+0xf9/0x490 [btrfs]   process_one_work+0x204/0x590   ? srso_return_thunk+0x5/0x5f   worker_thread+0x1d6/0x3d0   ? __pfx_worker_thread+0x10/0x10   kthread+0x118/0x230   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x205/0x260   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1a/0x30   </TASK>Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let s call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state.   0     4K    8K   |/////|/////|  (flag: DIRTY, tag: DIRTY)   <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages().   0     4K    8K   |/////|/////|  (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X s TOWRITE tag.   0     4K    8K   |     |/////|  (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won t see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.The Linux kernel CVE team has assigned CVE-2025-39779 to this issue.
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.master(6.12.33):不受影响
2.openEuler-20.03-LTS-SP4(4.19.90):不受影响
3.openEuler-22.03-LTS-SP3:不受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.openEuler-24.03-LTS:不受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:不受影响
8.openEuler-24.03-LTS-SP2:不受影响
9.openEuler-24.03-LTS-SP3:不受影响

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

原因说明：
  1.master(6.12.33):不受影响-漏洞代码不存在
2.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP3:不受影响-漏洞代码不存在
4.openEuler-22.03-LTS-SP4:不受影响-漏洞代码不存在
5.openEuler-24.03-LTS:不受影响-漏洞代码不存在
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-SP1:不受影响-漏洞代码不存在
8.openEuler-24.03-LTS-SP2:不受影响-漏洞代码不存在
9.openEuler-24.03-LTS-SP3:不受影响-漏洞代码不存在

src-openEuler / kernel
Closed

Content Risk Flag

Comments (8)

src-openEuler / kernelClosed .gitee-modal { width: 500px !important; }

Content Risk Flag

CVE-2025-39779

Comments (8)

Search

src-openEuler / kernel
Closed