CVE-2026-53319: Linux Kernel Block WBT DoS Vulnerability

CVE-2026-53319 Overview

CVE-2026-53319 affects the Linux kernel block layer, specifically the writeback throttling (blk-wbt) subsystem. The function wbt_init_enable_default() used WARN_ON_ONCE to check for failures returned by wbt_alloc() and wbt_init(). Both functions have expected failure paths: wbt_alloc() can return NULL under memory pressure with -ENOMEM, and wbt_init() can fail with -EBUSY when writeback throttling is already registered. Syzbot reproduced the issue by injecting memory allocation failures during Memory Technology Device (MTD) partition creation via ioctl(BLKPG), producing a spurious kernel warning and stack trace.

Critical Impact
A local user able to trigger allocation failures during block device registration can generate spurious kernel warnings, potentially aiding fault-injection based reconnaissance or triggering panic_on_warn systems into a denial-of-service state.

Affected Products

Linux kernel versions containing blk-wbt writeback throttling with the WARN_ON_ONCE check in wbt_init_enable_default()
Distributions shipping affected mainline and stable kernel branches
Systems configured with panic_on_warn enabled

Discovery Timeline

2026-06-26 - CVE-2026-53319 published to the National Vulnerability Database
2026-06-30 - Last updated in NVD database

Technical Details for CVE-2026-53319

Vulnerability Analysis

The defect resides in the Linux block layer writeback throttling code. wbt_init_enable_default() is invoked from blk_register_queue() as a best-effort initialization routine with a void return type. Failure to enable writeback throttling is not a safety condition; the disk simply operates without the throttling feature, which is harmless. Despite this, the original code wrapped calls to wbt_alloc() and wbt_init() in WARN_ON_ONCE, treating expected error returns as kernel bugs.

When wbt_alloc() fails under memory pressure or wbt_init() returns -EBUSY because writeback throttling has already been registered on the queue, the macro emits a full stack trace. On systems configured with panic_on_warn, this behavior escalates a benign initialization failure into a full kernel panic.

Syzbot triggered the condition reliably by injecting allocation failures while creating MTD partitions through the BLKPG ioctl. The fix replaces WARN_ON_ONCE with plain conditional checks, matching how wbt_set_lat() already handles the same error paths in the same source file. A pr_warn() call is added to preserve diagnostic information for the wbt_init() failure path without producing a stack trace.

Root Cause

The root cause is incorrect use of WARN_ON_ONCE on expected error return paths. WARN_ON_ONCE is intended to flag unexpected conditions that indicate kernel bugs, not routine allocation or registration failures. Treating -ENOMEM and -EBUSY returns as anomalies violates the contract of the warning macro and produces false positives.

Attack Vector

A local unprivileged or privileged user, depending on device permissions, can invoke ioctl(BLKPG) operations against block devices while the system is under memory pressure or during fault injection. The resulting spurious warning yields noise in kernel logs at minimum, and on hardened systems with panic_on_warn enabled it produces a denial-of-service through kernel panic. No verified public exploit code is available for this issue. See the upstream commits e9b004ff8306 and fd7a98265707 for the resolved fix.

Detection Methods for CVE-2026-53319

Indicators of Compromise

Kernel log entries containing WARNING: CPU: stack traces originating from wbt_init_enable_default or blk_register_queue
Unexpected kernel panics on hosts where panic_on_warn is enabled, correlated with block device or MTD partition operations
Repeated BLKPG ioctl invocations from unprivileged processes visible in audit logs

Detection Strategies

Monitor dmesg and /var/log/kern.log for stack traces referencing wbt_alloc, wbt_init, or wbt_init_enable_default
Enable Linux Audit rules on the ioctl syscall for block devices to capture unusual BLKPG activity
Correlate block device registration events with memory pressure metrics collected from /proc/pressure/memory

Monitoring Recommendations

Track kernel version inventory across the fleet and flag hosts running unpatched blk-wbt code
Alert on any host configured with panic_on_warn=1 that also runs kernel versions predating the fix commits
Ingest kernel ring buffer output into a centralized logging pipeline for retrospective analysis of warning traces

How to Mitigate CVE-2026-53319

Immediate Actions Required

Apply the upstream stable kernel patches referenced in commits e9b004ff8306 and fd7a982657077 and rebuild affected kernels
Deploy vendor-supplied kernel updates from the appropriate Linux distribution once available
Audit systems for panic_on_warn configuration and disable it where operationally acceptable until patches are deployed

Patch Information

The fix removes WARN_ON_ONCE from wbt_init_enable_default() and replaces it with plain if checks consistent with existing failure handling in wbt_set_lat(). A pr_warn() call is added to log wbt_init() failures without producing a stack trace. Patch commits are available at git.kernel.org commit e9b004ff8306 and git.kernel.org commit fd7a982657077.

Workarounds

Set panic_on_warn=0 at boot to prevent benign warnings from escalating into kernel panics on unpatched systems
Restrict access to block device nodes and BLKPG ioctl operations through appropriate file permissions and namespace isolation
Reduce exposure to fault-injection tooling by disabling CONFIG_FAULT_INJECTION on production kernels where not required

bash

# Verify panic_on_warn setting and disable if enabled
sysctl kernel.panic_on_warn
sysctl -w kernel.panic_on_warn=0

# Persist the setting across reboots
echo 'kernel.panic_on_warn = 0' > /etc/sysctl.d/99-cve-2026-53319.conf

# Confirm kernel version after patching
uname -r