CVE-2026-43094

What it actually does

This is a Linux kernel denial-of-service flaw in the ixgbevf virtual function network driver on Hyper-V. A missing negotiate_features callback in the Hyper-V-specific ixgbevf operations table leaves a NULL function pointer. During device probing, ixgbevf_negotiate_api() calls ixgbevf_set_features(), which dereferences that NULL callback and triggers a kernel NULL pointer dereference. The expected result is a kernel oops/panic or loss of availability of the affected virtual machine, depending on kernel panic settings and workload behavior. The issue is local in nature and requires the vulnerable driver path to be exercised on a Hyper-V VM using the affected ixgbevf code path.

Why it matters to the business

Successful exploitation can crash affected Linux virtual machines or disrupt networking during driver initialization, causing service downtime, failed boot or device attach workflows, and operational instability for workloads running on Hyper-V with the ixgbevf driver. The current exploitation likelihood appears low: EPSS is 0.00123 with no 30-day increase, it is not listed in CISA KEV, and no public exploit maturity is indicated. However, systems that rely on affected kernels in virtualized production environments may still face meaningful availability risk if local users, automation, or configuration changes can trigger driver probe/rebind events.

How an attack unfolds

An attacker first needs local access to an affected Linux guest or another permitted way to trigger the vulnerable ixgbevf driver probe path. On a Hyper-V virtual machine using the affected ixgbevf driver, the attacker causes the driver to initialize, reprobe, reload, or bind to the relevant virtual function device. During probe, ixgbevf_negotiate_api() attempts to negotiate mailbox/API features and calls through hw->mac.ops.negotiate_features. Because the Hyper-V operations table did not initialize that callback, the call target is NULL. The kernel dereferences address 0x0, producing a kernel oops or panic. The practical attacker outcome is denial of service: the VM may crash, reboot, lose networking, or become unstable. There is no indication from the provided data that this vulnerability enables privilege escalation, data theft, or remote code execution.

How to fix it

Upgrade affected Linux kernels to a version that includes the ixgbevf fix adding ixgbevf_hv_negotiate_features_vf() and wiring it into ixgbevf_hv_mac_ops. No exact fixed package versions were provided, so use the distribution/vendor kernel advisory for the specific platform and install the first kernel release that includes the CVE-2026-43094 fix or the upstream patch for the ixgbevf Hyper-V negotiate_features callback. After installing the fixed kernel, reboot into the updated kernel. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting sudo or device-management permissions, preventing untrusted users from loading/unloading kernel modules or rebinding PCI devices, and avoiding unnecessary ixgbevf device reprobe/reload operations on Hyper-V guests. Where operationally acceptable, use an alternate supported network driver/configuration until the kernel can be updated.

How to confirm the fix worked

Confirm the running kernel is from a vendor release that includes the ixgbevf Hyper-V negotiate_features fix. Verify with package metadata, distribution security advisories, changelogs, or source inspection that ixgbevf_hv_mac_ops includes a negotiate_features handler returning -EOPNOTSUPP. After rebooting, confirm the system is running the patched kernel with uname -a or equivalent package inventory tooling. Validate that Hyper-V guests using ixgbevf can boot, initialize networking, and reload/rebind the driver in a controlled maintenance window without producing a kernel NULL pointer dereference. Review kernel logs from the validation window for absence of ixgbevf_negotiate_api NULL dereference traces.

Typical attack path

1. Identify a Linux virtual machine running on Hyper-V with the affected ixgbevf driver/kernel code path.
2. Obtain local low-privileged access or access to an allowed administrative/automation path that can trigger driver initialization, reload, reprobe, or PCI device bind/unbind behavior.
3. Trigger the ixgbevf probe path, such as by causing the driver to load, reload, or rebind to the virtual function device.
4. The driver enters ixgbevf_negotiate_api() and calls the missing Hyper-V negotiate_features operation.
5. The kernel dereferences a NULL function pointer and logs a NULL pointer dereference/oops.
6. The affected VM experiences a crash, panic, reboot, networking failure, or service interruption.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, crash dumps, and hypervisor/VM availability events for crashes or oops messages involving the ixgbevf driver. Primary sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, kdump/vmcore records, crash utility output, and hypervisor event records showing guest resets or unexpected reboots. Look for a NULL pointer dereference at address 0000000000000000 with stack frames including ixgbevf_negotiate_api, ixgbevf_sw_init, ixgbevf_probe, local_pci_probe, and work_for_cpu_fn. Correlate these events with driver reloads, kernel upgrades, VM boot events, PCI device bind/unbind operations, network adapter changes, or automation that reprovisions virtual NICs. Evidence of exploitation is likely indistinguishable from accidental triggering unless correlated with suspicious local user activity, repeated intentional driver reprobes, unusual module management commands, or unauthorized use of privileged device-management interfaces.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• ixgbevf_negotiate_api
• ixgbevf_sw_init
• ixgbevf_probe
• Workqueue: events work_for_cpu_fn
• RIP: 0010:0x0
• Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine
• local_pci_probe
• ixgbevf
• hw->mac.ops.negotiate_features
• kernel NULL pointer dereference

What your security team should do

• Inventory Linux virtual machines running on Hyper-V and identify those using the ixgbevf driver or affected kernel versions.
• Prioritize patching production Hyper-V Linux guests where availability is critical or where local users can run code.
• Upgrade to a vendor kernel release that includes the ixgbevf Hyper-V negotiate_features fix, then reboot into the patched kernel.
• Until patched, restrict local interactive access and permissions that allow kernel module loading, driver reloads, PCI bind/unbind, or network device reprovisioning.
• Monitor kernel logs for NULL pointer dereferences involving ixgbevf_negotiate_api, ixgbevf_sw_init, or ixgbevf_probe.
• Review recent VM crashes, unexpected reboots, and network initialization failures on Hyper-V Linux guests for signs of this issue.
• Because this is not in KEV, has low EPSS, and has no known exploit maturity, handle as an availability-risk patching item rather than an emergency internet-exposed compromise scenario.