CVE-2026-80528 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid fs reclaim while using current->journal_info
handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply.
An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.:
Unable to handle kernel paging request at virtual address 00000000077b4818 [...]
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...]
Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...]
Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460
Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability identified in the Ceph client implementation involves a critical race condition within the memory management subsystem that leads to a kernel panic due to improper handling of journal handles during file system reclamation operations. The root cause lies in how the handle_reply function manages current thread context data while processing metadata server replies. Specifically, this function stores a pointer to a ceph_mds_request structure in the current task's journal_info field as part of populating inode and dentry caches from an MDS reply. This design choice creates a dangerous state where the kernel's memory reclaim subsystem misinterprets Ceph-specific request data as a valid JBD2 journal handle, leading to invalid memory dereferences when other file systems attempt to start transactions.
The operational impact manifests through a complex chain of events triggered by memory pressure scenarios. When an allocation occurs within the section of code where current->journal_info holds the ceph_mds_request pointer, the kernel may enter direct reclaim mode if sufficient free memory is not available. During this reclamation process, the virtual file system layer attempts to prune dentries from other mounted file systems such as ext4 to recover space. If this pruning operation dirties an inode belonging to the ext4 file system, ext4 initiates a JBD2 transaction via functions like __ext4_journal_start_sb and jbd2__journal_start. These journaling functions expect current->journal_info to contain either NULL or a valid struct handle_t pointer representing their own journal context. Instead, they encounter the ceph_mds_request structure left over from the Ceph operation.
This misinterpretation results in severe memory corruption because JBD2 attempts to access fields specific to its own data structures using offsets that do not align with those of the ceph request object. The code dereferences r_tid as h_transaction, which points to an invalid or non-existent address space relative to what JBD2 expects. This leads directly to a kernel paging request failure and subsequent Oops crash, effectively causing a denial of service for the entire system. The provided stack trace confirms this sequence, showing execution flowing from ceph_con_workfn through mds_dispatch and cache population functions into memory allocation paths that trigger shrink_slab operations on other superblocks, ultimately reaching jbd2__journal_start where the invalid pointer dereference occurs.
From a vulnerability classification perspective, this issue aligns with CWE-416 Use After Free or more accurately CWE-824 Access of Uninitialized Pointer in certain contexts, but primarily it represents a logic error leading to improper resource management and type confusion within kernel subsystems. In terms of the MITRE ATT&CK framework for enterprise security, while this is not an exploitable attack vector by external adversaries without significant preconditions like specific memory pressure configurations, it falls under T1499 Endpoint Denial of Service due to its potential to crash the host operating system through resource exhaustion interactions with kernel subsystems. The vulnerability highlights risks associated with global thread-local storage misuse across different subsystem boundaries within the Linux VFS layer.
Mitigation strategies focus on isolating filesystem-specific state from generic memory management contexts during critical operations. The primary technical fix involves entering a scoped NOFS allocation context before performing allocations that might trigger reclamation while current->journal_info is populated with Ceph data, and clearing this field immediately after use to prevent leakage into subsequent unrelated kernel paths. System administrators should ensure their kernels are updated to versions containing the patch for ceph: avoid fs reclaim while using current->journal_info. Additionally, monitoring systems detecting frequent OOM killer invocations or kernel panics related to jbd2 or ext4 interactions during heavy Ceph workloads can serve as early warning indicators of this condition manifesting in unpatched environments. Long-term architectural improvements should consider decoupling journal handle management from general thread-local storage used for diverse subsystem purposes to prevent cross-filesystem state contamination.