CVE-2023-53247
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-15

Last updated on: 2025-12-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand While trying to get the subpage blocksize tests running, I hit the following panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198 This happens because during btrfs_cont_expand we'll get a page, set it as mapped, and if it's not Uptodate we'll read it. However between the read and re-locking the page we could have called release_folio() on the page, but left the page in the file mapping. release_folio() can clear the page private, and thus further down we blow up when we go to modify the subpage bits. Fix this by putting the set_page_extent_mapped() after the read. This is safe because read_folio() will call set_page_extent_mapped() before it does the read, and then if we clear page private but leave it on the mapping we're completely safe re-setting set_page_extent_mapped(). With this patch I can now run generic/476 without panicing.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-15
Last Modified
2025-12-03
Generated
2026-05-27
AI Q&A
2025-09-15
EPSS Evaluated
2026-05-25
NVD
CVE-2023-53247
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel to 6.1.42 (exc)
linux linux_kernel From 6.2 (inc) to 6.4.7 (exc)
linux linux_kernel 6.5
linux linux_kernel 6.5
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-617 The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's btrfs filesystem code, specifically in the function btrfs_cont_expand. The issue arises because the code sets a page as mapped before reading it, but between reading and re-locking the page, the page could be released (release_folio called) while still being left in the file mapping. This can clear the page's private flag, causing a kernel panic when the code later tries to modify subpage bits. The fix was to move the set_page_extent_mapped call to after the read, ensuring safety even if the page private flag is cleared during release.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic (system crash) when using the btrfs filesystem under certain conditions, leading to potential system instability or downtime. It may disrupt normal filesystem operations and could affect system reliability.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version that includes the fix for the btrfs set_page_extent_mapped issue described. The fix involves changing the order of operations in btrfs_cont_expand to prevent kernel panics. Until the update is applied, avoid running workloads or tests that trigger btrfs subpage blocksize operations, such as the generic/476 test mentioned, to reduce the risk of kernel panic.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart