Linux Kernel EUVD-2026-45847

Triggering requires the host to be running the Linux idpf driver against supported Intel foundational NIC/IPU hardware AND to have PTP clock support active, with the fault occurring specifically during idpf_ptp_init() at driver load or a device HW reset (the log shows 'Device HW Reset initiated' immediately preceding the warning). Limiting factors: this is a local, hardware- and configuration-dependent init-time race - it is not reachable over the network despite the CVSS AV:N, it produces a lockdep warning rather than a controllable exploit primitive, and it does not occur on hosts lacking idpf hardware or with PTP disabled. No credible unauthenticated remote exploitation path exists against default configurations.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, base 9.8) is inconsistent with the vulnerability description and should be treated as an automated over-scoring: the bug is triggered by driver/PTP initialization on the local host, not by any network-delivered input, so a network attack vector is not supportable. All corroborating signals point to low real-world risk - EPSS is 0.15% (5th percentile), the CVE is not on CISA KEV, and no public exploit is identified. The practical worst case is a lockdep warning and a brief race on an uninitialized spinlock during init/reset, which is a robustness/correctness issue rather than a controllable primitive for privilege escalation or data theft. The 'Information Disclosure' tag in the input is not substantiated by the description, which describes a lock-init ordering fix with no leak of memory contents. Conflicting data explicitly noted: CVSS claims AV:N/PR:N/high CIA impact, but the description implies local, config/hardware-dependent triggering with no clear attacker-controlled impact - verify severity with the kernel advisory rather than trusting the 9.8.

During module load or a device HW reset on a host with an idpf-driven NIC and PTP enabled, the PTP aux kworker runs before the clock lock is initialized, hitting an uninitialized spinlock and generating a lockdep warning and a transient race. There is no remote attacker in this path and no public exploit; a local user could at most influence the timing of a driver reset, with no demonstrated path to code execution or data disclosure.