CVE-2023-53247: btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand
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.
Security readout for executives and security teams
Plain-English summary
CVE-2023-53247 is a Linux kernel Btrfs bug that can crash the system under local filesystem activity. The business impact is availability: affected hosts using Btrfs may panic, interrupting workloads. The provided sources do not show active exploitation or remote attack capability.
Executive priority
Handle in normal kernel patch cycles, with higher priority for production Btrfs systems exposed to shared or untrusted local workloads. There is no provided evidence of remote exploitation or KEV listing, but kernel panics can still cause material service disruption.
Technical view
The flaw is an assertion failure in Btrfs subpage handling during btrfs_cont_expand after read_folio can release page private state. Later subpage bit modification can hit a BUG and kernel panic. CVSS is 5.5 with local access, low complexity, low privileges, no user interaction, and high availability impact.
Likely exposure
Exposure is most relevant to Linux systems using Btrfs, especially kernels in the affected version data and workloads allowing local users or jobs to write to Btrfs-backed filesystems. Systems not using Btrfs are unlikely to be practically exposed based on the provided evidence.
Exploitation context
The evidence describes a panic found during filesystem stress testing, not public exploitation. KEV is false in the provided bundle. Treat this as a local denial-of-service risk where a low-privileged local actor or workload could potentially trigger unstable Btrfs behavior.
Researcher notes
The root issue is ordering around set_page_extent_mapped and read_folio in btrfs_cont_expand. The fix moves set_page_extent_mapped after the read because read_folio already maps before reading, and resetting the state after private data is cleared is safe per the source description.
Mitigation direction
Apply Linux vendor kernel updates containing the referenced upstream stable Btrfs fixes.
Prioritize Btrfs hosts with untrusted local users, shared workloads, or containerized write activity.
If patching is delayed, limit untrusted local access to Btrfs-backed filesystems.
Track distribution advisories for CVE-2023-53247 backport status.
Schedule maintenance windows for hosts where kernel updates require reboot.
Validation and detection
Inventory Linux hosts using Btrfs filesystems.
Compare running kernel packages against vendor advisories for CVE-2023-53247.
Confirm whether referenced upstream stable commits are included in your kernel build.
Review kernel logs for Btrfs BUG or assertion failures matching subpage.c:229.
Verify post-update kernels remain on supported vendor maintenance streams.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-617: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-617 · source CWE mapping
Reachable Assertion
Reachable Assertion represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.