CVE-2026-64509

What it actually does

This is a Linux kernel resource-lifetime bug in the Rust block-layer GenDisk cleanup path. If disk creation fails after __blk_mq_alloc_disk(), the error path can fail to drop the temporary gendisk reference and associated request_queue correctly. In some cases, especially when the last Arc<TagSet<T>> is moved into the build path, the leaked queue can retain blk-mq state after the tag set has been dropped. The practical technical impact is kernel memory/resource leakage and potentially unstable block-layer state during failure or teardown paths for Rust-based block devices. This is primarily a local reliability/denial-of-service class issue rather than a remotely exploitable vulnerability based on the available information.

Why it matters to the business

Systems running affected Linux kernel builds with Rust block-device functionality may experience kernel instability, memory/resource leakage, failed block-device cleanup, or crashes under specific block-device initialization and teardown failure conditions. Because this is not listed in CISA KEV, has no known ransomware association, has no known public exploit maturity, and has a very low EPSS score, broad active exploitation risk appears low; however, kernel flaws can still have high operational impact on systems that rely on affected block-layer components.

How an attack unfolds

An attacker would need a way to exercise the affected Rust block-device creation or teardown path, typically through local access, control of a relevant driver/module workflow, or another mechanism that repeatedly triggers failed GenDiskBuilder::build() operations after disk allocation but before successful registration. By forcing these failure paths, the attacker may cause leaked gendisk/request_queue objects or stale blk-mq state to accumulate. Repeated triggering could degrade system stability, exhaust kernel resources, or contribute to a kernel crash. There is no indication from the supplied data of remote unauthenticated exploitation, public exploit code, KEV listing, or named threat actor activity.

How to fix it

Upgrade to a Linux kernel build that includes the fix for the Rust block GenDisk cleanup paths. The corrected behavior drops the temporary gendisk reference with put_disk() on pre-registration failure and pairs GenDisk::drop() with put_disk() after del_gendisk(), allowing disk_release() to complete queue teardown correctly. If an immediate kernel upgrade is not possible, reduce exposure by disabling or avoiding affected Rust block-device drivers/features where operationally feasible, restricting local module loading and driver-management privileges, and limiting untrusted local access to systems that can exercise block-device creation paths.

How to confirm the fix worked

Confirm that the running kernel includes the upstream fix for the Rust block GenDisk cleanup path. Validate by checking the vendor kernel advisory/changelog for the backported fix, confirming the installed kernel package version against the vendor-fixed release, and ensuring the host has rebooted into the fixed kernel. For source-based builds, verify that GenDiskBuilder::build() error handling calls put_disk() for the temporary gendisk before recovering queue_data, and that GenDisk::drop() calls put_disk() after del_gendisk(). Operationally, test affected Rust block-device initialization and teardown failure scenarios and confirm there are no persistent gendisk/request_queue leaks, kmemleak reports, KASAN findings, or block-layer teardown warnings.

Typical attack path

1. Gain local ability to interact with or influence a Rust-based Linux block-device driver or module path.
2. Trigger disk build operations that progress past __blk_mq_alloc_disk() but fail before full registration.
3. Repeat the failure path so temporary gendisk and request_queue references are not released correctly on vulnerable kernels.
4. Cause kernel resource leakage, stale blk-mq state, instability, or denial of service.
5. Optionally monitor for system degradation, kernel warnings, or crashes resulting from repeated failed initialization/teardown.

How to detect it

Retrospective exploitation detection is difficult because this flaw is a cleanup/lifetime bug and does not produce a unique network signature or user-space artifact. Focus on host-based evidence from systems running affected kernels, especially those using Rust block drivers or custom block-device modules. Review kernel logs, persistent journal entries, crash dumps, and kernel sanitizers for repeated block-device creation failures, gendisk/request_queue leaks, blk-mq teardown warnings, KASAN use-after-free reports, kmemleak reports, kernel oopses, or panic traces involving Rust block-layer GenDisk cleanup. Also review audit logs or EDR telemetry for local users or processes repeatedly loading/unloading kernel modules, manipulating block devices, or triggering storage driver initialization failures shortly before kernel instability. No named threat actors, KEV exploitation, ransomware usage, or public exploit maturity were supplied, so detections should be framed as anomaly and crash-forensics searches rather than high-confidence compromise indicators.

• GenDiskBuilder::build
• __blk_mq_alloc_disk
• del_gendisk
• put_disk
• disk_release
• request_queue
• blk_mq
• blk-mq
• gendisk
• KASAN:
• BUG: KASAN:
• use-after-free
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• unreferenced object
• kmemleak
• /sys/kernel/debug/kmemleak
• /proc/modules
• /var/log/kern.log
• /var/log/messages
• /var/crash

What your security team should do

• Prioritize patching systems that run experimental or production Rust-based Linux block drivers, custom kernel modules, storage appliances, virtualization hosts, or other systems where block-layer reliability is critical.
• Track the relevant Linux distribution or kernel vendor advisory and deploy the first kernel version that includes the GenDisk cleanup fix; reboot systems to activate the fixed kernel.
• Restrict untrusted local shell access and limit privileges that allow kernel module loading, block-device driver manipulation, or access to experimental kernel features.
• Enable or review kernel telemetry on high-value systems, including kernel logs, crash dumps, KASAN/kmemleak output where available, and repeated block-device registration failure events.
• Treat unexplained kernel crashes, persistent block-layer warnings, or resource exhaustion on systems using Rust block drivers as candidates for deeper forensic review, even though known exploitation likelihood is currently low.