CVE-2026-64118

What it actually does

This is a Linux kernel memory-management flaw in the QLogic/Broadcom qed network driver. During context table allocation, a later PF or VF CID bitmap allocation failure can trigger cleanup in qed_cid_map_alloc(), which frees previously allocated CID bitmap memory. The caller then performs higher-level cleanup through qed_cxt_mngr_free(), which can invoke qed_cid_map_free() on the same pointers a second time. Double-free conditions in kernel memory can corrupt allocator metadata or allow freed memory to be reused in unsafe ways, potentially leading to kernel crash, denial of service, or, in favorable conditions, local privilege escalation and arbitrary kernel memory manipulation. Exploitation appears to require reaching a device-specific driver initialization or allocation-failure path, and no public exploit maturity is currently reported.

Why it matters to the business

Systems using affected Linux kernels with the qed driver exposed to relevant QLogic/Broadcom network hardware may be at risk of instability or compromise if an attacker can trigger the vulnerable allocation-failure path. The most likely operational impact is host crash or network-service disruption, but the CVSS assessment reflects potential confidentiality, integrity, and availability impact if kernel memory corruption is successfully weaponized. Because this is kernel-level code, successful exploitation could undermine host isolation and security controls. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely at this time; however, kernel memory corruption bugs should still be prioritized on systems running the affected driver, especially production virtualization, storage, or network-heavy hosts.

How an attack unfolds

An attacker first needs local ability to influence execution of the qed driver path, typically on a system with supported qed/qede hardware or a configuration that loads the driver. The attacker attempts to force or race a failure during one of the later CID bitmap allocations inside qed_cxt_tables_alloc(). When the allocation failure occurs, qed_cid_map_alloc() frees earlier CID bitmap allocations and returns an error. The caller then performs additional cleanup and frees the same bitmap pointers again because they were not cleared after the first free. If the attacker can shape memory allocation and reuse around this sequence, the double free may corrupt kernel heap state, causing a crash or potentially enabling privilege escalation. Practical exploitation is expected to be environment-specific because it depends on driver presence, hardware/device setup, kernel allocator behavior, and reliable triggering of an allocation-failure path.

How to fix it

Upgrade to a Linux kernel build that includes the qed fix, which clears each CID bitmap pointer after bitmap_free() so later cleanup does not free the same allocation again. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories and apply the first kernel update that references this qed double-free fix. Reboot after applying the kernel update to ensure the fixed kernel is active. Where immediate patching is not possible, reduce exposure by disabling or unloading the qed/qede driver if the hardware and driver are not required, preventing untrusted local users from accessing affected systems, limiting administrative actions that reload or reinitialize the driver, and using workload isolation for high-risk multi-user hosts. Mitigations should be treated as temporary because the vulnerable code remains present until the kernel is updated.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the distribution or vendor advisory that contains the qed fix. Verify whether the driver is present or loaded using standard module and hardware inventory checks such as lsmod, modinfo, lspci, and distribution package metadata. For source-based validation, inspect the qed driver cleanup path and confirm that CID bitmap pointers are set to NULL immediately after bitmap_free() in the failure path. If the driver was disabled as a mitigation, confirm it is not loaded and does not automatically load at boot. Exercise caution with runtime testing: intentionally forcing kernel allocation failures or driver initialization errors can crash production systems and should only be done in a controlled lab using debugging kernels or fault-injection frameworks.

Typical attack path

1. Identify a Linux host running an affected kernel with the qed/qede driver loaded or relevant QLogic/Broadcom network hardware present.
2. Gain local code execution or another local foothold capable of interacting with device initialization, driver reload, or resource-allocation behavior.
3. Attempt to trigger the qed context table allocation path while inducing a later PF or VF CID bitmap allocation failure.
4. Cause qed_cid_map_alloc() to free previously allocated CID bitmap memory during its failure cleanup path.
5. Allow the caller cleanup path to invoke qed_cid_map_free() again, producing a double free of the same kernel memory.
6. Leverage the resulting kernel heap corruption to crash the host or, if exploit primitives are reliable, escalate privileges or manipulate kernel memory.

How to detect it

There are no universally reliable indicators proving exploitation of this issue because successful kernel memory corruption may leave only crash artifacts or no durable evidence. Review kernel logs, persistent journal records, crash dumps, hypervisor reset events, and endpoint telemetry for signs of qed/qede driver initialization failures followed by allocator corruption, double-free detection, kernel BUG/Oops messages, KASAN reports, or unexpected reboots. Focus on systems where the qed/qede module is loaded or where compatible QLogic/Broadcom network devices are present. Useful log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, kernel crash dump directories such as /var/crash, kdump/vmcore artifacts, EDR process/session telemetry for local users preceding a crash, and audit logs showing module reloads, network device resets, or privileged driver-management commands. Investigate sequences involving qed/qede allocation errors immediately followed by slab allocator warnings such as double free, use-after-free, invalid free, general protection fault, kernel panic, or host reboot. Absence of these artifacts does not rule out exploitation, especially if logs were lost during a panic or the attacker gained kernel-level control.

• qed_cxt_tables_alloc
• qed_cid_map_alloc
• qed_cid_map_free
• qede
• qed
• KASAN: double-free
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG at
• general protection fault
• slab: double free
• double free detected
• invalid free
• kernel panic
• Oops:
• Call Trace:
• /var/crash
• vmcore
• kdump

What your security team should do

• Inventory Linux systems for affected kernel versions and presence of the qed/qede driver or compatible QLogic/Broadcom network adapters.
• Prioritize patching hosts where the qed/qede driver is loaded, especially multi-user systems, virtualization hosts, storage nodes, and critical network infrastructure.
• Apply vendor kernel updates that include the qed double-free fix and reboot systems to activate the patched kernel.
• If patching must be delayed, disable or blacklist the qed/qede driver where it is not operationally required, and document any systems where the driver must remain enabled.
• Restrict local shell access and privileged device-management capabilities on systems that require the affected driver until patched.
• Monitor kernel logs for allocation failures, double-free diagnostics, KASAN reports, allocator corruption messages, unexpected driver reloads, and unexplained reboots or kernel panics.
• Because no public exploit or KEV listing is currently reported, treat this as targeted/local-risk kernel hardening rather than an active mass-exploitation emergency, while still prioritizing affected high-value hosts.