Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T15:17:06.667Z",
  "pubdate": "2026-08-26T15:17:06.667Z",
  "executiveSummary": "This vulnerability is an improper synchronization issue in the Ceph filesystem client within the Linux kernel, specifically related to the misuse of the current->journal_info field during memory allocation and filesystem reclamation.\nThe vulnerability allows an attacker to trigger a kernel panic due to a pointer dereference error when a filesystem reclamation process (specifically via direct reclaim) interacts with external filesystem mechanisms like ext4 and JBD2.\nAffected systems are those running Ceph as a kernel client. The impact is a local denial-of-service (kernel crash).\nThe risk is categorized as critical because it results in system instability. Exploitation requires triggering specific memory pressure conditions while Ceph is performing MDS reply processing, which could potentially be triggered by an unprivileged user capable of influencing file system operations or directory traversal.\nThe root cause is that Ceph-specific data stored in current->journal_info is incorrectly interpreted by the JBD2 subsystem during nested filesystem operations, leading to a kernel paging request error.",
  "technicalDetails": "The vulnerability originates in the handle_reply() function of the Ceph kernel client. During the processing of MDS (Metadata Server) replies, the kernel stores a reference to a ceph_mds_request structure within the task_struct field current->journal_info. This field is typically reserved for journal-related data in filesystem drivers.\nWhen Ceph performs memory allocations during the filling of inode and dentry caches (such as during ceph_readdir_prepopulate), these allocations may invoke the kernel's memory management subsystem to trigger direct reclaim (shrink_slab). If the system is under memory pressure, the shrinker may initiate the pruning of dentries from other mounted filesystems, such as ext4.\nDuring this pruning process, if an ext4 inode is dirtied, the ext4 filesystem initiates a JBD2 transaction via ext4_journal_start_sb. The JBD2 subsystem expects current->journal_info to point to a valid journal handle (handle_t). However, because Ceph has repurposed this field to store a ceph_mds_request, JBD2 performs a type-unsafe cast, treating the pointer to the Ceph request as a handle_t structure.\nThe JBD2 subsystem subsequently attempts to dereference the request's r_tid field, interpreting it as a pointer to the transaction (h_transaction). Because the memory address contained in the Ceph request structure does not represent a valid kernel address for a transaction structure, a kernel paging request failure occurs (oops).\nThe attack flow follows these steps: 1) The user triggers a Ceph-specific operation (e.g., directory listing) that fills the cache and populates current->journal_info. 2) Memory allocation triggers a reclaim path. 3) The reclaim path touches an external filesystem (ext4). 4) JBD2 invokes a transaction start. 5) JBD2 misinterprets the Ceph object in current->journal_info as a journal handle. 6) The kernel attempts to dereference the invalid pointer, resulting in a system crash.\nThis issue is technically an improper scope of the process's journal information field, failing to respect the constraints required by nested filesystem operations. The fix involves wrapping the critical section in a scoped NOFS (No-FileSystem) allocation context, effectively preventing the recursion into other filesystems while the non-standard data is stored in the journal_info field."
}