CVE-2026-53289

What it actually does

This flaw is a Linux kernel NULL pointer dereference in the Intel Ethernet Connection E800-series `ice` driver SR-IOV virtual function reset path. When `ice_reset_all_vfs()` attempts to rebuild all virtual function VSIs and `ice_vf_rebuild_vsi()` fails, the driver can leave VSI queue mapping pointers such as `txq_map` and `rxq_map` unset. The vulnerable code then continues into post-rebuild logic and dereferences the NULL queue mapping pointer in `ice_ena_vf_q_mappings()`, causing a kernel oops or panic. The practical technical impact is denial of service of the host kernel, typically during a narrow operational window involving SR-IOV VF reset/rebuild activity and transitional NIC firmware state, such as an NVM firmware update.

Why it matters to the business

A successful trigger can crash affected Linux hosts using the `ice` network driver with SR-IOV virtual functions, interrupting workloads, virtual machines, containers, storage traffic, or network services dependent on those interfaces. Because the issue can occur during firmware maintenance, it can turn planned network adapter updates into unplanned host outages and may extend maintenance windows. The currently provided intelligence indicates low EPSS, no known CISA KEV listing, no ransomware association, and no public exploit maturity, so the primary risk is operational availability rather than broad internet-scale exploitation.

How an attack unfolds

An attacker or operator-controlled process must cause the vulnerable `ice` driver to reset all SR-IOV virtual functions while a VF VSI rebuild fails. One observed path is an NVM firmware update using tooling such as `nvmupdate64e`, where firmware is temporarily in a transitional state and Admin Queue commands used to rebuild/configure VSIs can fail. In the vulnerable kernel, `ice_reset_all_vfs()` does not properly stop after the failed rebuild. It proceeds to post-VSI-rebuild handling, which assumes queue maps are initialized. Because the failed rebuild error path has torn down the VSI and left fields such as `vsi->txq_map` NULL, the driver dereferences a NULL pointer in `ice_ena_vf_q_mappings()`. This causes a kernel page fault and can panic the host. Exploitation is therefore most plausible by a privileged local actor, maintenance process, or management-plane workflow capable of initiating NIC firmware updates, PCI/VF resets, SR-IOV reconfiguration, or driver rebinding on affected systems.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for `ice_reset_all_vfs()` so the driver checks the return value of `ice_vf_rebuild_vsi()` and skips post-rebuild handling when the rebuild fails. If a fixed kernel is not yet available from the operating system vendor, request the vendor backport for the `ice` driver fix or apply the relevant stable kernel update once released. As interim mitigations, avoid performing NIC NVM firmware updates on affected hosts while SR-IOV VFs are active; disable SR-IOV VFs before firmware maintenance where operationally feasible; migrate workloads away from hosts before NIC firmware updates; and schedule maintenance with rollback and console access. If a VF is left disabled after a failed rebuild, recover it using a VF PCI reset through sysfs or by rebinding the VF driver, rather than forcing repeated all-VF reset operations on an unpatched kernel.

How to confirm the fix worked

Confirm the running kernel contains the patched `ice` driver logic by checking the installed vendor advisory, kernel changelog, or source/package diff for the change in `ice_reset_all_vfs()` that handles `ice_vf_rebuild_vsi()` failure and skips `ice_vf_post_vsi_rebuild()` and `ice_eswitch_attach_vf()` on failure. Validate exposure by identifying systems with the `ice` module loaded and SR-IOV VFs enabled, for example by checking loaded modules, PCI devices, and `sriov_numvfs` values under `/sys/class/net/*/device/`. After patching, perform controlled maintenance testing in a non-production environment with SR-IOV enabled and NIC firmware update/reset workflows to confirm VF rebuild failures no longer produce a kernel oops or panic. Review `dmesg`, `journalctl -k`, crash dumps, and kernel panic records for absence of stack traces involving `ice_reset_all_vfs`, `ice_sriov_post_vsi_rebuild`, or `ice_ena_vf_q_mappings`.

Typical attack path

1. Identify a Linux host using an affected kernel with the Intel `ice` network driver and SR-IOV virtual functions enabled.
2. Gain sufficient local, administrative, or management-plane control to trigger NIC firmware update activity, SR-IOV VF reset/rebuild, PCI reset, or driver rebind operations.
3. Create or wait for a condition where VF VSI rebuild fails, such as during an NVM firmware update while the NIC firmware/Admin Queue is in a transitional state.
4. Trigger the all-VF reset path through the `ice` service task or related reset workflow.
5. The vulnerable driver continues into post-rebuild logic despite the failed VSI rebuild.
6. The driver dereferences a NULL `txq_map` or `rxq_map` pointer in the VF queue-mapping path.
7. The kernel oopses or panics, causing host-level denial of service and network/workload interruption.

How to detect it

To determine whether this issue was already triggered, review persistent kernel logs, system journals, crash dumps, kdump/vmcore analysis, hypervisor host logs, and maintenance records around NIC firmware updates or SR-IOV reconfiguration events. Key evidence includes a kernel oops or panic with a stack trace containing `ice_ena_vf_q_mappings`, `ice_sriov_post_vsi_rebuild`, `ice_reset_all_vfs`, or `ice_service_task`, especially near execution of `nvmupdate64e` or logs indicating NVM firmware update activity. In `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, and `dmesg` output, look for NULL pointer dereference or page fault messages attributed to the `ice` module. In crash dumps, confirm the faulting instruction path dereferenced `vsi->txq_map` or similar queue mapping state after a failed VSI rebuild. Also correlate with host reboots, watchdog resets, VM/workload outages, link flaps, VF reset events, and PCI driver unbind/rebind actions. There are no reliable remote network indicators for this vulnerability because the observable evidence is primarily local kernel and maintenance-tool artifacts.

• ice_ena_vf_q_mappings
• ice_sriov_post_vsi_rebuild
• ice_reset_all_vfs
• ice_vf_rebuild_vsi
• ice_vsi_rebuild
• ice_service_task
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Unable to handle kernel NULL pointer dereference
• asm_exc_page_fault
• page_fault_oops
• COMMAND: "nvmupdate64e"
• nvmupdate64e
• ice_aq_read_nvm
• ice_aq_send_cmd
• ice_sq_send_cmd
• VFGEN_RSTAT
• VFACTIVE
• /sys/class/net/*/device/sriov_numvfs
• /sys/bus/pci/devices/*/reset

What your security team should do

• Inventory Linux systems using the Intel `ice` driver, especially hosts with SR-IOV enabled for virtualization, NFV, storage, or high-performance networking workloads.
• Prioritize kernel or vendor driver updates on affected SR-IOV-enabled hosts even though current exploitation signals are low, because the failure mode is a full host crash.
• Pause or tightly control NIC NVM firmware updates on unpatched hosts; migrate workloads or disable VFs before maintenance where feasible.
• Ensure crash dump collection, persistent kernel logging, and out-of-band console access are enabled before network adapter firmware maintenance.
• Create SOC detections for kernel oops/panic traces referencing `ice_ena_vf_q_mappings`, `ice_sriov_post_vsi_rebuild`, `ice_reset_all_vfs`, and concurrent `nvmupdate64e` activity.
• Document operational recovery steps for disabled VFs, including sysfs PCI reset or driver rebind procedures.
• Monitor vendor advisories for fixed kernel package versions and apply the relevant stable or enterprise distribution updates when available.