CVE-2025-39879
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-23

Last updated on: 2025-12-12

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ceph: always call ceph_shift_unused_folios_left() The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array. However, since commit ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method"), this shifting doesn't happen anymore because the "for" loop got moved to ceph_process_folio_batch(), and now the `i` variable that remains in ceph_writepages_start() doesn't get incremented anymore, making the shifting effectively unreachable much of the time. Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write() method") added more preconditions for doing the shift, replacing the `i` check (with something that is still just as broken): - if ceph_process_folio_batch() fails, shifting never happens - if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens - if `processed_in_fbatch` is zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way: BUG: kernel NULL pointer dereference, address: 0000000000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023 Workqueue: writeback wb_workfn (flush-ceph-1) RIP: 0010:folios_put_refs+0x85/0x140 Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 > RSP: 0018:ffffb880af8db778 EFLAGS: 00010207 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003 RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0 RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0 R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000 FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> ceph_writepages_start+0xeb9/0x1410 The crash can be reproduced easily by changing the ceph_check_page_before_write() return value to `-E2BIG`. (Interestingly, the crash happens only if `huge_zero_folio` has already been allocated; without `huge_zero_folio`, is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL entries instead of dereferencing them. That makes reproducing the bug somewhat unreliable. See https://lore.kernel.org/[email protected] for a discussion of this detail.) My suggestion is to move the ceph_shift_unused_folios_left() to right after ceph_process_folio_batch() to ensure it always gets called to fix up the illegal folio_batch state.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-23
Last Modified
2025-12-12
Generated
2026-05-07
AI Q&A
2025-09-23
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39879
Affected Vendors & Products
Showing 6 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.15 (inc) to 6.16.8 (exc)
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's Ceph component involves improper handling of folio_batch entries. The function ceph_process_folio_batch() sets some entries to NULL, which is illegal, and the function ceph_shift_unused_folios_left() is supposed to remove these NULL entries. However, due to changes in the code, this shifting no longer happens reliably, leaving NULL entries in the array. This can lead to a kernel crash caused by a NULL pointer dereference when the kernel later tries to access these invalid entries.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to crash due to a NULL pointer dereference. Such crashes can lead to system instability, potential data loss, and denial of service as the kernel becomes unresponsive or restarts unexpectedly.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel crash with a NULL pointer dereference in the ceph_writepages_start() function, often visible in kernel logs with messages like 'BUG: kernel NULL pointer dereference' and call traces involving ceph_writepages_start and folios_put_refs. Detection involves monitoring kernel logs (e.g., using 'dmesg' or 'journalctl -k') for such crash signatures. Specific commands to check kernel logs include: 'dmesg | grep -i ceph', 'journalctl -k | grep -i ceph', or 'grep -i "BUG: kernel NULL pointer dereference" /var/log/kern.log'.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is fixed, ensuring that the function ceph_shift_unused_folios_left() is properly called after ceph_process_folio_batch() to prevent illegal folio_batch states and kernel crashes. If updating is not immediately possible, monitoring for kernel crashes and avoiding workloads that trigger ceph_process_folio_batch() failures may reduce risk, but no direct workaround commands are provided.


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