CVE-2026-45962

What it actually does

This is a local Linux kernel memory-safety flaw in the ublk subsystem. The vulnerable code path in ublk_ctrl_cmd_dump() reads the io_uring SQE command area before verifying that the submission queue entry was created with the required IO_URING_F_SQE128 flag. A local user who can reach the ublk control interface can submit a malformed uring command that causes an out-of-bounds kernel memory access. The assessed impact is primarily availability: the most likely outcome is a kernel oops, panic, or system crash. No confirmed confidentiality or integrity impact is indicated by the supplied scoring.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, storage services, containers, or applications that depend on the host. Because exploitation is local and requires some level of local access, broad internet-scale exploitation is less likely; however, shared systems, developer machines, build hosts, container platforms, and multi-user Linux environments face higher operational risk. EPSS is currently very low and the issue is not listed in CISA KEV, so remediation should be prioritized according to local exposure to untrusted users and use of the ublk/io_uring functionality rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host, such as through a shell account, compromised service account, container escape-adjacent foothold with relevant device access, or another local code execution path. The attacker then interacts with the ublk control path using io_uring and submits a crafted command without the IO_URING_F_SQE128 flag. On vulnerable kernels, the ublk control handler dereferences the SQE command area before validating that the larger 128-byte SQE layout is present. This can cause the kernel to read outside the expected SQE memory boundary. Depending on kernel configuration, memory layout, and hardening features, the result is likely a kernel warning, oops, or panic, causing denial of service for the host and the workloads running on it.

How to fix it

Upgrade to a vendor-supported Linux kernel version that includes the upstream fix moving the SQE128 flag validation earlier in ublk_ctrl_uring_cmd() so invalid SQEs return -EINVAL before the command area is accessed. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution or appliance vendor advisory. If immediate patching is not possible, reduce exposure by disabling or unloading the ublk kernel module where not required, avoiding CONFIG_BLK_DEV_UBLK in custom kernels when unused, restricting access to ublk control devices, limiting local shell access to trusted users, and applying available io_uring restrictions such as kernel.io_uring_disabled where operationally acceptable. Treat mitigations as temporary because they may reduce attack surface but do not correct the vulnerable code path.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel is a vendor build containing the ublk SQE128 validation fix, not merely that an updated package is installed but not booted. Check the active kernel with uname -r and compare it to the distribution advisory or kernel changelog for the ublk change referencing early IO_URING_F_SQE128 validation in ublk_ctrl_uring_cmd(). On systems where ublk is not required, validate that the module is not loaded with lsmod | grep ublk and that ublk device nodes are absent or access-controlled. Where safe test coverage exists, malformed ublk io_uring requests that previously caused a crash should now fail cleanly with EINVAL. Also validate that kernel crash logs no longer show faults in ublk_ctrl_cmd_dump or ublk_ctrl_uring_cmd after local testing or normal operation.

Typical attack path

1. Gain local code execution or authenticated local access on an affected Linux system.
2. Confirm that the ublk subsystem and relevant device/control interface are available.
3. Create an io_uring instance capable of issuing the ublk control command path.
4. Submit a malformed ublk uring command that omits the IO_URING_F_SQE128 flag.
5. Trigger the vulnerable pre-validation access in ublk_ctrl_cmd_dump().
6. Cause an out-of-bounds kernel memory access, resulting in a kernel oops, panic, or host denial of service.

How to detect it

Look for signs of prior local exploitation or crash attempts in kernel and system logs rather than network telemetry, because this is a local kernel attack surface. Review journalctl -k, dmesg archives, /var/log/kern.log, /var/log/messages, crash dump metadata, kdump/vmcore records, and EDR telemetry for kernel oops, panic, page fault, general protection fault, or KASAN reports involving ublk_ctrl_cmd_dump, ublk_ctrl_uring_cmd, ublk, or io_uring. Correlate crash timestamps with local user sessions, sudo/authentication logs, container runtime events, suspicious binaries or scripts that invoke io_uring, and unexpected access to /dev/ublk-control or ublk device nodes. If kernel crash dumps are available, inspect stack traces for ublk control functions and malformed uring command paths. Absence of these artifacts does not prove non-exploitation, because a successful denial-of-service attempt may leave limited logs if the host panicked before logs were flushed.

• ublk_ctrl_cmd_dump
• ublk_ctrl_uring_cmd
• IO_URING_F_SQE128
• /dev/ublk-control
• /dev/ublkc
• /dev/ublkb
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at
• Kernel panic - not syncing
• Oops:
• RIP: .*ublk_ctrl_cmd_dump
• RIP: .*ublk_ctrl_uring_cmd
• Call Trace:.*ublk
• io_uring
• ublk

What your security team should do

• Inventory Linux hosts running kernels with ublk support, especially multi-user systems, container hosts, storage nodes, CI/build workers, and developer workstations.
• Prioritize kernel updates on systems where untrusted or semi-trusted users can execute local code or access ublk-related device nodes.
• Apply vendor kernel updates and reboot into the fixed kernel; track systems that have installed but not activated the fixed kernel.
• If patching is delayed, disable or restrict ublk functionality where not business-critical and review permissions on ublk control devices.
• Consider temporarily restricting io_uring for untrusted workloads if compatible with applications and platform policy.
• Monitor kernel logs and crash telemetry for oops, panic, KASAN, or page-fault events referencing ublk_ctrl_cmd_dump, ublk_ctrl_uring_cmd, ublk, or io_uring.
• Because there is no KEV listing, no known ransomware association, and no mature public exploit indicated, prioritize according to local exposure rather than emergency internet-facing patch SLAs.