CVE-2023-53247

MEDIUM EPSS 3.2%
Published Sep 15, 20259mo ago · Modified Jun 17, 20261w ago
5.5 CVSS 3.1
Medium
Find Similar
Published Sep 15, 2025 9mo ago
Last Modified Jun 17, 2026 1w ago

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 Details

Base Score
5.5
Exploitability
1.8
Impact
3.6
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector Local
Attack Complexity Low
Privileges Required Low
User Interaction None
Scope Unchanged
Confidentiality None
Integrity None
Availability High

Threat Intelligence

EPSS Exploit Probability
3.2% percentile
Exploit & Patch Status
No Known Exploit
Patch Available

Weaknesses 1

CWE-617

Affected Products 4

VendorProductVersionRange
linuxlinux_kernel* <6.1.42
linuxlinux_kernel*≥6.2  –  <6.4.7
linuxlinux_kernel6.5any
linuxlinux_kernel6.5any

References 3

  • git.kernel.org https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b
    Patch

Remediation

  • git.kernel.org https://git.kernel.org/stable/c/0a5e0bc8e8618e32a6ca64450867628eb0a627bf
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/17b17fcd6d446b95904a6929c40012ee7f0afc0c
    Patch
  • git.kernel.org https://git.kernel.org/stable/c/a5880e69cf7fe4a0bb1eabae02205352d1b59b7b
    Patch