CVE-2026-46080

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel OCFS2 filesystem direct I/O write completion path. During OCFS2 direct I/O operations, extent updates can require more JBD2 journal transaction credits than the maximum allowed for a single transaction, causing journal warnings and potentially failed or unstable filesystem operations. The fix splits extent processing into transaction-sized batches and ensures orphan-list removal and inode size updates occur only after extent tree updates complete, reducing the risk of credit exhaustion and inconsistent post-crash filesystem state.

Why it matters to the business

Systems using OCFS2 may experience filesystem instability, failed I/O, service interruption, or node/application downtime if a local user or workload triggers the vulnerable direct I/O path. The impact is primarily availability-related and is most relevant to clustered Linux environments that rely on OCFS2 for shared storage. This issue is not known to be exploited in the wild, is not listed in CISA KEV, and has a very low EPSS score, so urgency is moderate unless OCFS2 is used on production or high-availability storage nodes.

How an attack unfolds

An attacker must already have local access to a Linux system and sufficient privileges to write to an OCFS2-mounted filesystem. They perform direct I/O writes that cause OCFS2 to update many unwritten extents during write completion. On vulnerable kernels, the write completion path attempts to process too much extent metadata in a single journal transaction, exhausting JBD2 transaction credits. This can trigger kernel journal warnings and may disrupt filesystem operations or cause availability degradation. The vulnerability does not provide remote code execution or privilege escalation by itself; exploitation depends on local access and the presence of OCFS2.

How to fix it

Upgrade the Linux kernel to a version that includes the OCFS2 fix for splitting direct I/O completion extent updates across multiple journal transactions and delaying orphan-list removal until extent tree updates complete. Because no exact fixed package versions were provided, use the latest stable kernel or distribution vendor kernel advisory that references this OCFS2/JBD2 credit exhaustion fix. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting write permissions to OCFS2 mounts, avoiding untrusted workloads on systems using OCFS2, and monitoring or temporarily disabling workloads that perform heavy direct I/O to OCFS2 filesystems.

How to confirm the fix worked

Confirm exposure by checking whether OCFS2 is in use and whether the running kernel predates the vendor fix. Review mounted filesystems with commands such as `findmnt -t ocfs2`, `mount | grep ocfs2`, or inspection of `/proc/mounts`. Validate remediation by confirming the host is running a patched vendor kernel and by reviewing the kernel changelog or package advisory for the OCFS2 direct I/O transaction batching fix. After remediation, monitor kernel logs during representative OCFS2 direct I/O workloads and confirm that JBD2 credit exhaustion warnings no longer appear.

Typical attack path

1. Gain local access to a Linux host that has an OCFS2 filesystem mounted.
2. Identify a writable file or directory on the OCFS2 mount.
3. Issue direct I/O write workloads that create or complete many extent updates.
4. Trigger OCFS2 direct I/O completion handling that attempts to consume excessive JBD2 journal credits.
5. Cause journal warnings, failed filesystem operations, or broader availability impact affecting workloads dependent on the OCFS2 filesystem.

How to detect it

Look for evidence in kernel and system logs that OCFS2 direct I/O operations triggered JBD2 transaction credit exhaustion or related filesystem errors. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, and distribution-specific system logs. Search for JBD2 warnings mentioning too many credits, OCFS2 write completion or extent update failures, and call traces involving `ocfs2_dio_end_io_write`, `ocfs2_mark_extent_written`, `ocfs2_change_extent_flag`, `ocfs2_split_extent`, `ocfs2_extend_trans`, or `jbd2__journal_restart`. Correlate these messages with local user sessions, batch jobs, database workloads, or processes performing heavy direct I/O against OCFS2 mounts. Because there are no public reports of exploitation and no known actor activity, detection is primarily behavior- and log-based rather than signature-based.

• JBD2: kworker
• wants too many credits
• rsv_credits:0
• max:5449
• ocfs2_dio_end_io_write
• ocfs2_mark_extent_written
• ocfs2_change_extent_flag
• ocfs2_split_extent
• ocfs2_try_to_merge_extent
• ocfs2_extend_rotate_transaction
• ocfs2_extend_trans
• jbd2__journal_restart
• start_this_handle
• /proc/mounts
• ocfs2

What your security team should do

• Inventory Linux systems for OCFS2 usage and prioritize shared-storage or clustered production systems.
• Patch affected systems to a vendor-supported kernel containing the OCFS2 direct I/O completion fix.
• If patching is delayed, restrict local user access and write permissions to OCFS2-mounted filesystems.
• Monitor kernel logs for OCFS2, JBD2, journal credit, and filesystem error messages that may indicate attempted triggering or operational impact.
• Coordinate with storage, database, and platform teams before rebooting clustered OCFS2 nodes to avoid service disruption during kernel upgrades.
• Treat this as lower urgency than remotely exploitable or KEV-listed issues, but prioritize it where OCFS2 supports critical availability-sensitive workloads.