CVE-2026-64162: Linux Kernel Race Condition Vulnerability

CVE-2026-64162 Overview

CVE-2026-64162 affects the Linux kernel idpf (Intel Infrastructure Data Path Function) network driver. The vulnerability stems from an incorrect initialization order in idpf_ptp_init(), where the read_dev_clk_lock spinlock is initialized after ptp_schedule_worker() has already been scheduled. The Precision Time Protocol (PTP) auxiliary worker fires immediately upon scheduling and can invoke idpf_ptp_read_src_clk_reg_direct(), which acquires the uninitialized lock. This triggers a lockdep "non-static key" warning and creates a race condition on kernel data structures used by the PTP clock subsystem.

Critical Impact
A race condition on the read_dev_clk_lock spinlock allows the PTP auxiliary worker to acquire an uninitialized lock, resulting in undefined synchronization behavior and potential kernel instability on systems using Intel idpf-driven network adapters.

Affected Products

Linux kernel builds that include the idpf network driver
Systems using Intel Infrastructure Data Path Function devices with PTP enabled
Kernel branches prior to the commits referenced in git.kernel.org fixes

Discovery Timeline

2026-07-19 - CVE-2026-64162 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64162

Vulnerability Analysis

The defect resides in the idpf_ptp_init() initialization path of the idpf driver. The function calls ptp_schedule_worker() before invoking spin_lock_init(&ptp->read_dev_clk_lock). Because the PTP auxiliary worker (ptp_aux_kworker) executes as soon as it is scheduled, it can reach idpf_ptp_update_cached_phctime() and subsequently idpf_ptp_read_src_clk_reg_direct() before the spinlock backing structure is valid. That path calls spin_lock(&ptp->read_dev_clk_lock) on memory that has never been registered with the lockdep subsystem, producing the recorded stack trace ending in _raw_spin_lock+0x30/0x40.

Root Cause

The root cause is an initialization ordering error [Race Condition]. spin_lock_init() must complete before any code path that acquires the lock becomes reachable. In the vulnerable version, the worker thread and the setter path (idpf_ptp_settime64()) both become live before the spinlock is initialized, violating that invariant.

Attack Vector

Exploitation requires a device reset or driver load that triggers the idpf_ptp_init() code path on affected hardware. The condition surfaces during normal driver initialization, as shown in the reported log entry idpf 0000:83:00.0: Device HW Reset initiated. The vulnerability manifests as concurrent access to uninitialized synchronization primitives. Consult the upstream commits referenced in Kernel Git Commit 3122d70b, Kernel Git Commit da4f76b6, and Kernel Git Commit eb5991d4 for the exact source ranges affected.

// No verified proof-of-concept code is available.
// The fix moves spin_lock_init(&ptp->read_dev_clk_lock)
// ahead of ptp_schedule_worker() in idpf_ptp_init()
// so the lock is valid before any worker can touch it.

Detection Methods for CVE-2026-64162

Indicators of Compromise

Kernel log entries containing INFO: trying to register non-static key immediately following idpf driver initialization or a device HW reset.
Lockdep stack traces referencing idpf_ptp_read_src_clk_reg, idpf_ptp_update_cached_phctime, and ptp_aux_kworker.
Unexpected soft lockups or scheduling anomalies on hosts using Intel idpf-managed NICs with PTP enabled.

Detection Strategies

Monitor dmesg and journalctl -k output for the exact lockdep warning signature tied to idpf_ptp_init.
Correlate driver initialization events with subsequent PTP worker stack traces to confirm the ordering fault.
Track kernel package versions across the fleet and flag hosts running builds that predate the referenced upstream commits.

Monitoring Recommendations

Forward kernel ring buffer logs to a centralized log platform and alert on register_lock_class warnings originating from idpf.
Baseline device reset frequency (Device HW Reset initiated) per host so that repeated resets on idpf interfaces are surfaced for triage.
Include kernel version and loaded module inventory in endpoint telemetry to identify unpatched systems.

How to Mitigate CVE-2026-64162

Immediate Actions Required

Identify all Linux hosts loading the idpf module, especially those with PTP hardware clocks enabled on Intel network adapters.
Update to a Linux kernel that includes the fixes referenced in the upstream commits 3122d70b, da4f76b6, and eb5991d4.
Reboot affected systems after patching so the corrected initialization order takes effect on the next driver load.

Patch Information

The upstream fix moves spin_lock_init(&ptp->read_dev_clk_lock) earlier in idpf_ptp_init() so that the spinlock is fully initialized before ptp_schedule_worker() runs and before idpf_ptp_settime64() can be reached. Apply the vendor-supplied kernel update that backports these commits to your distribution's stable branch.

Workarounds

Where patching is not immediately feasible, disable PTP functionality on idpf-managed interfaces to prevent the worker from reaching the uninitialized lock.
Avoid manual device resets (ethtool --reset) on idpf NICs until the kernel is updated.
Unload the idpf module on hosts that do not require the driver, reducing exposure until a patched kernel is deployed.

bash

# Verify kernel version and confirm whether idpf is loaded
uname -r
lsmod | grep idpf

# Check kernel log for the lockdep signature associated with CVE-2026-64162
dmesg | grep -E "idpf|non-static key|read_dev_clk_lock"

# After updating the kernel package, reboot to apply the fix
sudo reboot