CVE-2026-64017

What it actually does

This is a Linux kernel use-after-free flaw in the blk-mq block I/O submission path. A race can occur when a task peeks at a cached block request, then blocks before removing it from the cache; a plug flush may free the cached request while it is still expected to be usable. Subsequent use of the freed request can corrupt kernel memory or trigger a kernel crash. Because exploitation occurs in kernel context and the CVSS vector is local with low privileges required, the practical impact is local privilege escalation, denial of service, and potential compromise of confidentiality and integrity on affected systems.

Why it matters to the business

An attacker who already has local access to an affected Linux system could potentially crash the host or gain elevated privileges, turning a limited foothold into full system control. For servers running affected Red Hat Enterprise Linux 9 kernels, this can create operational risk for workloads that depend on host stability, including virtualized, containerized, and storage-heavy environments. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at 0.0012 with no known public exploit maturity, but kernel local privilege-escalation flaws should still be prioritized on multi-user systems, shared compute, and systems exposed to untrusted local workloads.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected system, such as through a low-privileged shell, compromised service account, container escape prerequisite, or another initial access path. The attacker then attempts to exercise the block I/O submission path in a way that triggers the blk-mq cached request race: a cached request is observed, execution blocks before it is removed from the cache, and a plug flush frees the same request. If the attacker can reliably shape allocation and timing, the freed kernel object may be reused or dereferenced, producing memory corruption. Depending on exploit reliability and available kernel hardening, this may result in a kernel panic or could be weaponized to modify kernel memory and elevate privileges. There is currently no indication from the provided data that public exploit code, named threat actors, KEV exploitation, or ransomware campaigns are using this vulnerability.

How to fix it

Apply the vendor kernel update for affected Red Hat Enterprise Linux 9 systems. The fixed Red Hat package version is kernel 5.14.0-687.31.1.el9_8, released under RHSA-2026:47040. After installing the updated kernel package, reboot into the fixed kernel; installing the package alone is not sufficient if the system continues running an older kernel. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, enforcing container isolation and least privilege, disabling unnecessary interactive accounts, and prioritizing hosts that run shared workloads or allow untrusted users to execute code. There is no reliable configuration-only mitigation for the underlying kernel memory-safety flaw.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is at or above the fixed Red Hat Enterprise Linux 9 build. Use commands such as `uname -r`, `rpm -q kernel`, and vendor advisory tooling to verify that the system has booted into `5.14.0-687.31.1.el9_8` or a later fixed kernel. Check bootloader defaults to ensure the fixed kernel is selected after reboot. Validate with vulnerability scanners or Red Hat advisory checks that RHSA-2026:47040 is no longer applicable. For environments using golden images, templates, or container hosts, confirm the base image and all derivative deployments have been rebuilt and rebooted onto the fixed kernel.

Typical attack path

1. Gain local code execution on an affected Linux host with a low-privileged account or workload context.
2. Identify that the host is running a vulnerable Red Hat Enterprise Linux 9 kernel prior to the fixed build.
3. Run a local program that generates and times block I/O activity to exercise the vulnerable blk-mq cached request path.
4. Trigger the race between cached request handling and plug flushing so that a request is freed while still usable.
5. Attempt to convert the resulting kernel use-after-free into a kernel crash or controlled memory corruption.
6. If exploitation is successful, elevate privileges or destabilize the host.

How to detect it

Look for signs of attempted or successful local exploitation rather than network indicators, because this vulnerability requires local code execution. Primary sources are kernel logs, system journal, crash dumps, EDR process telemetry, audit logs, and host reboot history. Search for kernel oops, panic, KASAN, slab corruption, or general protection fault messages involving the block layer, blk-mq, request allocation/free paths, or the functions named in the advisory. Correlate suspicious kernel faults with recent execution by low-privileged users, unexpected binaries in temporary directories, stress-test style disk I/O utilities, compiler activity, privilege changes, or sudden creation of setuid files. Also review unexpected reboots or host crashes on systems running vulnerable kernels. Absence of logs does not prove absence of exploitation because successful kernel exploitation may avoid leaving distinctive artifacts, and crash logs may be lost if persistent logging or kdump is not enabled.

• blk_mq_free_plug_rqs
• blk-mq
• use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• slab-use-after-free
• blk_mq_submit_bio
• bio plug merge
• cached_rqs
• RHSA-2026:47040
• 5.14.0-687.31.1.el9_8

What your security team should do

• Patch and reboot affected Red Hat Enterprise Linux 9 systems to kernel 5.14.0-687.31.1.el9_8 or later, prioritizing shared, multi-user, container-hosting, virtualization, CI/CD, and storage-intensive systems.
• Inventory running kernels across Linux fleets and flag systems that have the fixed package installed but have not rebooted into the fixed kernel.
• Restrict local access on vulnerable systems until patched, especially for untrusted users, build jobs, third-party workloads, and exposed application service accounts.
• Review recent kernel crash, panic, and KASAN logs for evidence of blk-mq or block-layer memory corruption, especially on systems where untrusted local code may have run.
• Monitor vendor advisories and exploit intelligence because kernel local privilege-escalation vulnerabilities can become more urgent if exploit code is released, even when initial EPSS is low.
• Ensure endpoint telemetry captures process execution, privilege changes, kernel oops/panic events, and unexpected reboots to support post-exploitation investigation.