CVE-2026-43346

What it actually does

This vulnerability affects the Linux kernel Intel E800-series Ethernet driver path for the ice driver when Precision Time Protocol (PTP) is initialized in certain VFIO passthrough configurations. If a physical function is passed through to a virtual machine but that function does not own the adapter source timer, the driver's controlling PTP physical function pointer may be absent. The vulnerable code treats this expected state as a kernel warning via WARN_ON() rather than a supported-but-unavailable condition. On systems configured to panic on kernel warnings, this can turn a driver initialization condition into a local denial of service by triggering a kernel panic. The impact is availability only; it does not provide direct confidentiality or integrity compromise.

Why it matters to the business

Systems using Linux with Intel ice network adapters, especially virtualization hosts or environments using VFIO PCI passthrough, may experience unexpected host or guest disruption if this driver condition triggers a kernel warning that is configured to panic the system. The practical consequence is service interruption for workloads dependent on the affected host, network interface, or passed-through device. The risk is lower for most organizations because exploitation requires local access and a specific hardware/virtualization configuration, EPSS is very low, it is not listed in CISA KEV, and there is no known mature public exploit activity.

How an attack unfolds

An attacker would first need local access to a Linux system or access to an administrative or delegated workflow that can influence VFIO passthrough of an Intel ice physical function. The attacker then arranges or triggers a configuration where a passed-through physical function does not own the PTP source timer. During ice driver PTP setup, the kernel attempts to locate the controlling PTP physical function, receives a NULL result, and reaches the vulnerable WARN_ON() path. If the system is configured with panic_on_warn or equivalent policy, the warning escalates to a kernel panic, interrupting the host or guest. In environments without panic-on-warning behavior, the event is more likely to appear as a kernel warning and driver/PTP setup failure rather than a full system outage.

How to fix it

Upgrade to a Linux kernel version or distribution kernel update that includes the ice driver fix replacing the WARN_ON() condition with an informational message and returning -EOPNOTSUPP when the controlling PTP physical function is unavailable. Because fixed package versions were not provided, use the latest security-supported kernel from the operating system vendor and confirm that the vendor advisory includes the fix for this issue. As interim mitigations, avoid passing through Intel ice physical functions that do not own the PTP source timer, disable or avoid PTP features for affected passthrough devices where operationally acceptable, restrict who can configure VFIO passthrough, and review whether kernel.panic_on_warn is required on systems where availability is more important than crash-on-warning diagnostics.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported version containing the corrected ice PTP behavior. Validate using distribution package metadata, vendor advisories, or kernel changelogs referencing the ice PTP change that avoids WARN_ON() when the controlling PF is unavailable. On test systems with representative hardware, reproduce the affected VFIO passthrough scenario and verify that PTP setup returns an unsupported-operation condition or logs an informational message rather than emitting a kernel WARNING or panicking. Also check sysctl settings such as kernel.panic_on_warn to understand whether any remaining kernel warnings could cause outages.

Typical attack path

1. Gain local access to a Linux system or to a management path that can influence VFIO PCI passthrough configuration.
2. Identify a system using the Intel ice network driver with PTP support and a passthrough-capable physical function.
3. Configure or trigger passthrough of a physical function that does not own the adapter source timer.
4. Cause the ice driver to initialize PTP for that physical function.
5. Trigger the WARN_ON() condition in the ice PTP setup path when the controlling PTP physical function is unavailable.
6. If kernel warning panic behavior is enabled, cause a kernel panic and denial of service.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, hypervisor logs, and crash dump records for warnings or panics involving the Intel ice driver PTP setup path. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg archives, kdump/vmcore records, hypervisor event logs, and configuration-management records showing VFIO passthrough changes. Look for kernel WARNING entries naming ice_ptp_setup_pf, ice_get_ctrl_ptp, the ice module, PTP initialization, or stack traces followed by panic, reboot, or watchdog events. Correlate these with recent VFIO passthrough changes, PCI device assignment events, VM start events, or changes to kernel.panic_on_warn. There are no known network-based indicators for this issue because exploitation is local and configuration-driven.

• ice_ptp_setup_pf
• ice_get_ctrl_ptp
• WARNING: CPU:
• Kernel panic - not syncing
• panic_on_warn
• Modules linked in: ice
• ice: ptp
• PTP
• VFIO
• vfio-pci
• adapter->ctrl_pf
• EOPNOTSUPP

What your security team should do

• Prioritize patching Linux virtualization hosts and systems using Intel ice network adapters with VFIO passthrough.
• Inventory systems loading the ice kernel module and correlate them with VFIO passthrough, SR-IOV, or PTP usage.
• Apply the latest vendor kernel security update that contains the corrected ice driver behavior.
• Restrict VFIO passthrough configuration rights to trusted administrators and controlled automation only.
• Review kernel.panic_on_warn settings on affected systems and ensure the setting aligns with operational availability requirements.
• Monitor kernel logs for ice PTP warnings, NULL controlling PF conditions, and unexpected reboots or kernel panics.
• Treat exploitation likelihood as low in general internet-facing risk models, but elevate priority for dense virtualization platforms where a local-triggered outage could affect many workloads.