CVE-2026-46066

What it actually does

This is a local denial-of-service flaw in the Linux kernel CephFS client writeback path for encrypted files. Under memory pressure, allocation of a crypto bounce buffer can fail while processing a batch of dirty folios. In a specific discontiguous-write scenario, the Ceph writeback accounting field tracking the number of write extents can be incremented and not corrected when the folio is not actually added to the batch. Later, ceph_submit_write() observes inconsistent operation counts and triggers a kernel BUG_ON(), causing a kernel panic. The impact is availability loss of the affected host; the flaw does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

An authenticated local user or workload that can write to fscrypt-enabled CephFS files may be able to crash an affected Linux system, causing service interruption, failed jobs, node reboots, and potential disruption to clustered or containerized workloads using CephFS. Risk is highest where untrusted or multi-tenant users can write to encrypted CephFS mounts and where systems can experience memory pressure. The issue is not listed in CISA KEV, is not known to be used in ransomware, and has a low EPSS score, so it should be prioritized as an availability hardening and reliability fix rather than an internet-scale emergency.

How an attack unfolds

An attacker first needs local access or the ability to run a workload on a Linux system that mounts and writes to encrypted CephFS files. The attacker writes to a file using a pattern that creates dirty folios separated by gaps, such as alternating 4 KiB written and 4 KiB skipped ranges. They then create or wait for memory pressure so allocation of the temporary crypto bounce buffer fails during encrypted writeback. If the failed folio is not contiguous with the previous folio already placed in the writeback batch, the kernel can miscount the number of write extents. When CephFS submits the write request, the internal operation index no longer matches the expected number of request operations, causing the kernel BUG_ON() in the Ceph client path and panicking the system.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream CephFS fix correcting ceph_wbc->num_ops accounting when move_dirty_folio_in_page_array() fails. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance kernel advisory and confirm that the patch for this issue is included. Where immediate patching is not possible, reduce exposure by limiting local shell/container access, restricting who can write to fscrypt-enabled CephFS mounts, applying memory and I/O controls to untrusted workloads, monitoring and preventing sustained memory pressure, and avoiding encrypted CephFS writeback workloads on vulnerable kernels where feasible. Because this is a kernel panic condition, mitigations should be treated as temporary; the reliable fix is a patched kernel and reboot into that kernel.

How to confirm the fix worked

Confirm the running kernel build is from a vendor release that contains the CephFS num_ops accounting fix for this issue. Validate that systems were rebooted into the patched kernel, not merely had a package installed. On source-based or custom kernels, confirm the CephFS client code decrements ceph_wbc->num_ops when move_dirty_folio_in_page_array() fails after starting a new empty extent. For exposure validation, identify systems using CephFS mounts and determine whether fscrypt-enabled files are present. Higher-risk systems combine CephFS, encrypted file writeback, local writable access by untrusted workloads, and memory pressure. Optional non-production testing can reproduce the historical failure mode by writing an alternating 4 KiB write/4 KiB hole pattern to encrypted CephFS files while applying controlled memory pressure; patched kernels should not panic.

Typical attack path

1. Obtain local user access, container workload execution, or another path to write files on a host using CephFS.
2. Target a CephFS mount where file encryption through fscrypt is enabled.
3. Create or modify files using a sparse or alternating write pattern, such as 4 KiB written followed by 4 KiB skipped repeatedly.
4. Increase memory pressure or time the activity during existing memory pressure so crypto bounce-buffer allocation is more likely to fail.
5. Trigger encrypted CephFS writeback of the dirty folio batch.
6. Cause the CephFS writeback accounting mismatch to reach ceph_submit_write().
7. Kernel hits the BUG_ON condition and panics, causing denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal logs, crash dumps, and monitoring alerts for kernel BUG or panic events involving the CephFS client writeback path. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore records, kdump/vmcore analysis, hypervisor reset events, and node-level availability monitoring. Look for crashes containing ceph_submit_write, CephFS address-space/writeback functions, or BUG/Oops messages near memory allocation failures, direct reclaim, OOM activity, or heavy writeback. Correlate panic timestamps with local users, containers, batch jobs, or services writing sparse or alternating-block files to encrypted CephFS mounts. Also review memory-pressure telemetry, OOM killer events, cgroup memory throttling, and CephFS mount activity around the crash. There are no known public actor-specific or ransomware indicators for this CVE, so detection should focus on behavioral evidence of local triggering: encrypted CephFS writes, discontiguous/sparse write patterns, memory pressure, followed by a CephFS kernel BUG/panic.

• ceph_submit_write
• move_dirty_folio_in_page_array
• ceph_process_folio_batch
• BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops)
• kernel BUG
• Kernel panic
• Oops:
• ceph:
• CephFS
• fscrypt
• Out of memory
• oom-killer
• page allocation failure
• writeback

What your security team should do

• Inventory Linux systems using CephFS, especially those with fscrypt-enabled encrypted files or directories.
• Prioritize patching for multi-tenant hosts, container nodes, build workers, HPC systems, and any service where untrusted users can write to CephFS.
• Upgrade to a kernel release from the OS or appliance vendor that includes the CephFS fix, then reboot and verify the active kernel version.
• Until patched, restrict write access to encrypted CephFS mounts and apply workload memory limits to reduce the chance of forced allocation failures.
• Add monitoring for kernel BUG, panic, and CephFS writeback errors on systems using CephFS.
• Review recent crash logs for CephFS-related kernel panics to determine whether the issue may already have been triggered.
• Treat unexplained repeated node crashes during CephFS encrypted write workloads as a potential denial-of-service attempt or abusive workload pattern.
• Because there is no KEV listing, no known ransomware use, and low EPSS, track this under kernel availability risk while still patching promptly during normal kernel maintenance cycles.