CVE-2026-53286

What it actually does

This is a Linux kernel memory-safety flaw in the idpf network driver error-handling paths for auxiliary device registration. If auxiliary_device_add() fails while plugging a vport or core auxiliary device, the cleanup path can call auxiliary_device_uninit(), which releases and frees the associated driver object, and then continue using fields from that freed object and free it again. The result is a use-after-free and double-free condition in kernel memory. Practical impact is most likely a kernel crash or system instability, but kernel use-after-free and double-free bugs can sometimes be developed into local privilege escalation if an attacker can reliably trigger the vulnerable error path and shape kernel heap memory.

Why it matters to the business

Systems using affected Linux kernels with the idpf driver may be vulnerable to crashes or instability during device initialization, reinitialization, hotplug, driver reload, or related error conditions. For organizations that rely on idpf-backed network interfaces, this could interrupt network connectivity or host availability. There is no indication that this vulnerability is in CISA KEV, used in ransomware, or currently has public exploit maturity; the EPSS score is low, so broad active exploitation is not currently expected. However, because the flaw is in kernel code, affected fleet segments should still be patched through normal kernel maintenance windows, especially on hosts where untrusted local users, containers, or workloads can influence device or driver lifecycle behavior.

How an attack unfolds

An attacker would need a way to run code locally or otherwise influence conditions that cause the idpf driver to initialize or plug auxiliary devices and then fail inside auxiliary_device_add(). The attacker attempts to force or race an error path, for example by repeatedly loading, unloading, resetting, or reconfiguring the relevant network device while creating resource-pressure conditions that make auxiliary device registration fail. In the vulnerable path, the driver releases the auxiliary device object, which invokes the release callback and frees the backing structure. Execution then falls through and accesses the freed object to release the IDA slot and calls kfree() again. This corrupts kernel memory and can produce a kernel oops, panic, or network-driver failure. A more advanced exploit would try to reclaim the freed kernel heap object with attacker-controlled data before the stale access or second free, potentially turning the memory corruption into privilege escalation, though no public exploit maturity is currently reported.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the idpf auxiliary-device error paths. Because no product-specific fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Prioritize systems where the idpf driver is loaded, where Intel idpf-supported networking hardware or virtual functions are present, or where untrusted local users/workloads can influence device resets, module loading, or resource exhaustion. If immediate patching is not possible, reduce exposure by preventing untrusted users from loading/unloading kernel modules, restricting administrative access to network device reset/reconfiguration operations, disabling or blacklisting the idpf module where it is not required, and avoiding unnecessary hotplug/reload workflows for affected devices until patched.

How to confirm the fix worked

Confirm the installed kernel includes the vendor fix for this issue by checking the running kernel version against the distribution or vendor security advisory. Verify whether the idpf module is present or loaded with commands such as lsmod, modinfo idpf, and by checking /sys/module/idpf when applicable. After remediation, confirm the system is booted into the updated kernel, not merely that updated packages are installed. Review kernel logs during idpf driver initialization, reset, or reload testing to ensure there are no KASAN, slab, double-free, use-after-free, oops, or panic messages referencing idpf auxiliary-device functions. Where feasible in test environments, exercise driver reload/reset paths after patching and confirm stable behavior.

Typical attack path

1. Identify a Linux host running an affected kernel with the idpf driver present and in use or loadable.
2. Obtain local execution or another capability that can influence driver/device lifecycle, reset, probe, or resource-pressure conditions.
3. Trigger idpf auxiliary-device initialization for vport or core device paths.
4. Cause auxiliary_device_add() to fail during the vulnerable initialization path, such as through fault injection, resource exhaustion, or repeated device reset/reload activity.
5. The vulnerable cleanup path frees the auxiliary device backing object, then uses the freed object and frees it again.
6. Observe a kernel crash, network-driver failure, or attempt advanced heap manipulation to pursue kernel-level code execution or privilege escalation.

How to detect it

To determine whether exploitation or triggering has already occurred, review kernel and system logs for crashes or memory-corruption reports around idpf driver initialization, reset, reload, probe failure, or auxiliary-device registration failure. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops crash logs, vmcore/kdump artifacts, hypervisor reset logs, and endpoint telemetry for module load/unload activity. Look for KASAN, KFENCE, slab allocator, BUG, oops, panic, general protection fault, or NULL/invalid pointer messages that reference idpf_plug_vport_aux_dev(), idpf_plug_core_aux_dev(), idpf_vport_adev_release(), idpf_core_adev_release(), auxiliary_device_add(), auxiliary_device_uninit(), ida_free(), or kfree(). Also investigate unusual repeated idpf module reloads, network device resets, sudden loss of idpf-backed interfaces, or host reboots correlated with local administrative commands or workload activity. Because the known symptoms are kernel memory corruption rather than a stable exploit artifact, absence of these logs does not prove the flaw was never triggered, especially if logs were lost during a panic or reboot.

• idpf_plug_vport_aux_dev
• idpf_plug_core_aux_dev
• idpf_vport_adev_release
• idpf_core_adev_release
• auxiliary_device_add
• auxiliary_device_uninit
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• KASAN: double-free
• BUG: KASAN: double-free
• BUG: KASAN: invalid-free
• kernel BUG at mm/slub.c
• general protection fault
• kernel panic
• Oops:
• idpf
• modprobe idpf
• rmmod idpf
• /sys/module/idpf
• /lib/modules/*/kernel/drivers/net/ethernet/intel/idpf/idpf.ko

What your security team should do

• Inventory Linux systems running kernels that include or load the idpf driver, with special attention to virtualization, high-performance networking, and systems using Intel idpf-supported network devices.
• Patch affected kernels through the appropriate distribution or vendor channel and reboot systems into the fixed kernel.
• Prioritize hosts where untrusted local users, containers, CI jobs, or tenants have any path to influence device resets, module operations, or resource exhaustion.
• If patching is delayed, restrict module-management and network-device administration privileges, and disable or blacklist idpf on systems where it is not required.
• Monitor kernel logs for idpf-related crashes, KASAN reports, slab allocator errors, and unexpected host reboots or network-interface resets.
• Do not treat this as an internet-facing remote code execution issue based on currently available information; response urgency should be driven by kernel exposure, idpf usage, local access risk, and operational criticality.