CVE-2026-46162

What it actually does

This is a Linux kernel memory-corruption flaw in the Intel Ethernet "ice" driver error-handling path. If auxiliary_device_add() fails during ice_sf_eth_activate(), the code calls auxiliary_device_uninit(), whose release callback frees the sf_dev object, and then execution can fall through to a second kfree() of the same object. This double free can corrupt kernel heap state and may allow a local low-privileged attacker who can trigger the affected driver path to crash the kernel or potentially gain elevated privileges, depending on kernel configuration, allocator hardening, and reachable heap layout.

Why it matters to the business

Successful exploitation could result in host crashes, service interruption, or local privilege escalation to kernel-level control on systems using affected Linux kernels with the impacted Intel ice driver functionality. Because the issue is local and EPSS is currently very low, broad internet-scale exploitation is unlikely, but systems that run untrusted local workloads, shared compute, containers with device access, or network-management tooling that can exercise this driver path should prioritize remediation to reduce outage and privilege-escalation risk.

How an attack unfolds

An attacker first needs local code execution or another way to interact with the affected kernel driver path. They then attempt to trigger activation of the affected ice subfunction Ethernet device while causing auxiliary_device_add() to fail. On the vulnerable error path, the kernel releases the subfunction device object through auxiliary_device_uninit(), and the associated release callback frees the object. Because the code can then fall through and free the same allocation again, kernel heap metadata or a later allocation can be corrupted. In the simplest case this causes a kernel oops or panic; with sufficient control over timing, heap grooming, and allocator behavior, the double free may be shaped into privilege escalation or arbitrary kernel memory corruption.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the ice driver double-free error path. Because no exact fixed package versions were provided, use distribution vendor advisories for the applicable kernel stream and install the first kernel release that backports the fix for CVE-2026-46162. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by disabling or unloading the ice driver if the hardware is not required, restricting local shell access, limiting access to device-management capabilities, preventing untrusted workloads from accessing host network devices, and applying kernel hardening features such as lockdown, module-loading restrictions, and allocator/KASLR protections where operationally feasible.

How to confirm the fix worked

Confirm that systems are running a kernel version or vendor kernel package that includes the fix, not merely that packages were downloaded. Validate with the running kernel version after reboot, distribution advisory status, and kernel changelog/backport references for the ice driver fix. Check whether the ice module is loaded or built in, and whether Intel ice-supported network hardware is present. If mitigations were used, verify that the ice module cannot be loaded or that the affected functionality is not reachable. For regression validation, monitor kernel logs after update for absence of double-free, use-after-free, KASAN, slab corruption, or ice driver activation errors under normal network operations.

Typical attack path

1. Obtain local execution on a system running an affected Linux kernel with the Intel ice driver and relevant subfunction support present.
2. Identify whether the affected driver path is reachable, typically through local network-device, auxiliary-device, or driver-management interfaces.
3. Trigger ice_sf_eth_activate() while inducing an auxiliary_device_add() failure condition.
4. Cause the vulnerable error path to call auxiliary_device_uninit(), freeing the sf_dev object through the device release callback.
5. Allow execution to fall through to the second free of the same sf_dev allocation.
6. Leverage the resulting kernel heap corruption to crash the host or attempt privilege escalation.

How to detect it

Look for evidence that the vulnerable driver path was triggered and that kernel heap corruption followed. Relevant sources include kernel ring buffer output, system journal kernel logs, /var/log/kern.log, /var/log/messages, crash dump infrastructure such as kdump/vmcore, audit logs for local user activity around the time of crashes, and endpoint telemetry showing device-management commands or module operations. Search for double-free, slab, KASAN, KFENCE, BUG, oops, panic, or general protection fault messages involving the ice driver, ice_sf_eth_activate(), ice_sf_dev_release(), auxiliary_device_add(), auxiliary_device_uninit(), or kfree(). Because this vulnerability does not define a unique network payload and exploitation is local, detection should focus on host telemetry, suspicious local privilege-escalation behavior after driver errors, and repeated attempts to exercise network-driver or auxiliary-device activation paths. If named threat actors are not known and KEV status is false, prioritize anomaly-based host review over signature-only detection.

• ice_sf_eth_activate
• ice_sf_dev_release
• auxiliary_device_add
• auxiliary_device_uninit
• double free
• KASAN: double-free
• BUG: KASAN: double-free
• kernel BUG
• general protection fault
• slab corruption
• KFENCE
• kfree
• ice:
• /var/log/kern.log
• /var/log/messages
• /proc/modules
• ice

What your security team should do

• Inventory Linux systems using the Intel ice driver or Intel Ethernet adapters supported by the ice driver, and rank internet-facing, shared, multi-tenant, and untrusted-workload hosts first.
• Patch affected systems through the appropriate distribution kernel update channel and reboot into the fixed kernel.
• Where patching is delayed, restrict local user access and block untrusted workloads from interacting with host network device-management interfaces.
• Disable or unload the ice driver on systems that do not require affected Intel Ethernet hardware.
• Enable or retain kernel exploit mitigations such as module-signing enforcement, lockdown mode, unprivileged eBPF restrictions, KASLR, and allocator hardening where supported.
• Monitor for kernel oops, panic, KASAN, slab corruption, and ice driver activation failure messages that could indicate attempted triggering or instability.
• Treat unexplained crashes on affected hosts as potential security events and collect kernel logs, crash dumps, loaded module lists, and recent local user/process activity before rebuilding or rebooting where feasible.