CVE-2026-46061

What it actually does

This Linux kernel flaw is an availability vulnerability in the jbd2 journaling layer used by ext4. A lock-ordering regression in jbd2_journal_cancel_revoke() can cause an ABBA deadlock between a folio lock and a buffer lock when the filesystem block size is smaller than the system page size. A local user or process that can perform filesystem operations may be able to trigger kernel threads or user processes to hang during ext4 journaling and writeback activity. The expected impact is denial of service: affected systems may experience stuck tasks, blocked filesystem operations, unresponsive applications, or require reboot to recover. There is no indication from the provided data that this flaw enables code execution, privilege escalation, or data disclosure.

Why it matters to the business

The primary business risk is service disruption on Linux systems using affected kernel builds, especially where ext4 filesystems are configured with block sizes smaller than the host page size. Exploitation or accidental triggering can cause filesystem operations to hang, affecting application availability, batch jobs, build systems, storage-heavy workloads, or hosts that rely on ext4-backed data paths. The CVSS score reflects high availability impact, but EPSS is very low and there is no known CISA KEV listing or reported ransomware use, so prioritization should focus on exposed multi-user systems, shared compute platforms, and production systems where local users, containers, or workloads can drive intensive filesystem activity.

How an attack unfolds

An attacker needs local ability to run code or otherwise cause filesystem activity on an affected Linux system. The attacker targets an ext4 filesystem where the filesystem block size is smaller than the kernel page size, then repeatedly performs operations that create or modify directory and file metadata while also encouraging writeback or synchronization activity. Under the vulnerable lock ordering, one execution path can hold a buffer lock and then wait on a folio lock, while another path holds the folio lock and waits on the buffer lock. If the timing aligns, both paths block each other indefinitely. The result is a kernel-level deadlock affecting filesystem operations; depending on workload and mount usage, this can lead to hung processes, stalled services, blocked I/O, and potentially a system that requires administrative intervention or reboot.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the jbd2 fix for jbd2_journal_cancel_revoke() lock ordering. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the corrected kernel for each distribution and release stream. After updating, reboot into the patched kernel and remove or de-prioritize older vulnerable kernels where operationally appropriate. As interim mitigations, restrict untrusted local shell access, reduce the ability of untrusted workloads to perform high-volume filesystem metadata operations on ext4 volumes, prefer patched kernels for multi-tenant or shared systems, and monitor for hung task symptoms. Where feasible, review ext4 filesystems with block sizes smaller than system page size, because those configurations are specifically implicated by the deadlock condition.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version after reboot and matching it against the distribution vendor’s advisory for this issue. Validate that the patched kernel contains the jbd2 change that avoids unnecessary __find_get_block_nonatomic() lookup when the passed buffer_head already belongs to the block device. On representative systems, confirm ext4 filesystems and block sizes using tools such as tune2fs and compare them with the system page size reported by getconf PAGESIZE. Review kernel logs after update for absence of repeated hung-task, blocked writeback, ext4, or jbd2 deadlock messages during normal filesystem activity. If regression testing is possible, run filesystem stress or ext4/jbd2-focused tests on non-production systems and confirm they no longer hang.

Typical attack path

1. Gain local execution capability on an affected Linux host, such as through a shell, scheduled job, container workload, or unprivileged local account.
2. Identify or rely on an ext4 filesystem whose block size is smaller than the system page size.
3. Generate repeated filesystem metadata operations, such as directory creation or file creation, to exercise ext4 journaling paths.
4. Concurrently trigger or wait for writeback/sync activity that exercises block device writeback paths.
5. Race the vulnerable jbd2 lock ordering until a folio lock and buffer lock deadlock occurs.
6. Cause affected filesystem operations, applications, or kernel tasks to hang, resulting in denial of service.

How to detect it

To determine whether the issue may already have been triggered, review kernel and system logs for hung task reports, blocked I/O, ext4/jbd2 call traces, and processes stuck in uninterruptible sleep during filesystem operations. Useful log sources include dmesg, journald/kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore analysis, and monitoring telemetry for sudden increases in load average with low CPU usage and blocked tasks. Look for call traces containing jbd2_journal_cancel_revoke(), __find_get_block_nonatomic(), ext4_journal_get_create_access(), ext4_getblk(), block_write_full_folio(), lock_buffer(), writeback, or sync_blockdev(). Because this is a deadlock/denial-of-service condition, there may be no attacker-specific artifact; indicators are primarily kernel symptoms and workload timing. Correlate log events with local user sessions, container workloads, batch jobs, or scripts performing heavy directory/file creation, deletion, or sync operations on ext4 filesystems. If crash dumps are available, inspect blocked task stacks for ABBA-style contention between folio_lock and buffer locking in ext4/jbd2/writeback paths.

• jbd2_journal_cancel_revoke
• __find_get_block_nonatomic
• ext4_journal_get_create_access
• ext4_getblk
• ext4_append
• ext4_init_new_dir
• ext4_mkdir
• sync_blockdev
• blkdev_writepages
• writeback_get_folio
• block_write_full_folio
• lock_buffer
• folio_lock
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• task jbd2/
• jbd2/
• ext4
• ABBA deadlock
• generic/013

What your security team should do

• Prioritize patching shared Linux servers, multi-user systems, container hosts, build runners, storage-heavy systems, and production hosts using ext4.
• Inventory Linux kernel versions across the fleet and map them to vendor advisories that include the jbd2 deadlock fix.
• Identify ext4 filesystems with block sizes smaller than the system page size, as these are the most relevant exposure condition described for the bug.
• Restrict untrusted local access and limit high-volume filesystem stress workloads until affected systems are patched.
• Monitor kernel logs for hung tasks involving jbd2, ext4, writeback, folio locking, or lock_buffer paths.
• After patching, confirm systems have rebooted into the fixed kernel; merely installing the package is not sufficient for kernel vulnerabilities.
• Treat exploitation likelihood as currently low based on very low EPSS, no known public exploit maturity, and no KEV listing, but still remediate where availability is operationally critical.