Look up another CVE · open CVE-2026-64162 in the interactive tracker

CVE-2026-64162

idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()

9.8 EPSS 0.3% AV:N

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-64162 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.12-1	Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

In idpf_ptp_init(), read_dev_clk_lock is initialized after ptp_schedule_worker() had already been called (and after idpf_ptp_settime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpf_ptp_read_src_clk_reg_direct(), which takes spin_lock(&ptp->read_dev_clk_lock) on an uninitialized lock, triggering the lockdep "non-static key" warning: [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dump_stack_lvl+0x93/0xe0 [12974.097234] register_lock_class+0x4c4/0x4e0 [12974.097249] ? __lock_acquire+0x427/0x2290 [12974.097259] __lock_acquire+0x98/0x2290 [12974.097272] lock_acquire+0xc6/0x310 [12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190 [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350 [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp] [12974.097343] _raw_spin_lock+0x30/0x40 [12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097391] ? kthread_worker_fn+0x88/0x3d0 [12974.097404] ? kthread_worker_fn+0x4e/0x3d0 [12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf] [12974.097428] ? _raw_spin_unlock_irq+0x28/0x50 [12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf] [12974.097454] ptp_aux_kworker+0x20/0x40 [ptp] [12974.097464] kthread_worker_fn+0xd5/0x3d0 [12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? __pfx_kthread+0x10/0x10 [12974.097498] ret_from_fork+0x32c/0x410 [12974.097512] ? __pfx_kthread+0x10/0x10 [12974.097519] ret_from_fork_asm+0x1a/0x30 [12974.097540] </TASK> Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock is not touched before it's been initialized.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/ethernet/intel/idpf/idpf_ptp.c

What this is: INTEL ETHERNET DRIVERSMAINTAINERS section matched on drivers/net/ethernet/intel/*/ · intel-wired-lan@lists.osuosl.org · Maintained
Kernel module: idpf

Check it on the machine

grep -wE 'CONFIG_ETHERNET|CONFIG_IDPF|CONFIG_NET_VENDOR_INTEL|CONFIG_PTP_1588_CLOCK' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w idpf

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.

bookworm, trixie?
forky, sidMnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x

?: not established - no Makefile entry for the affected file
M: a module where it is built at all; some flavours do not build it

Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.

Build switches: CONFIG_ETHERNET, CONFIG_IDPF, CONFIG_NET_VENDOR_INTEL, CONFIG_PTP_1588_CLOCK
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-19 (3 months ago)source
CVSS: 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.35%, higher than 26.7% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.16	6.18.34	eb5991d4c8ba
6.16	7.0.11	3122d70b7c01
6.16	7.1	da4f76b6a84e

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: On internet-facing cloud or datacenter hosts using Intel idpf NICs, a remote peer can send sustained or crafted traffic that stalls TX completion, triggering `idpf_tx_timeout()` → hardware reset → `idpf_vc_core_init()` → `idpf_ptp_init()`, which reaches the uninitialized `read_dev_clk_lock` via the immediately scheduled PTP aux worker or `idpf_ptp_settime64()`.
AC:LAttack complexity, low: Once PTP reinitialization runs with device clock access enabled, `ptp_schedule_worker(..., 0)` fires the aux kworker immediately and races deterministically with the late `spin_lock_init()`; the attacker does not need to win a timing lottery beyond causing the reset that enters this path.
PR:NPrivileges required, none: Triggering the vulnerable init path via TX-timeout-driven hardware reset requires no target-system privileges—only the ability to send traffic to a network interface managed by idpf, including unauthenticated remote access to a publicly reachable server.
UI:NUser interaction, none: Exploitation is fully automated once the attacker induces the reset/recovery sequence; no victim login, configuration change, or other voluntary action is required.
S:UScope, unchanged: Impact is confined to kernel/driver state on the host running idpf; it does not cross a VM, container, or IOMMU security boundary into another authority.
C:HConfidentiality impact, high: Using `spin_lock()` on an uninitialized (zeroed) lock allows concurrent, unsynchronized entry into `idpf_ptp_read_src_clk_reg_direct()` and shared PHC/MMIO read paths, creating a race on kernel/driver state that can be leveraged for information disclosure under the kernel CNA guidance for synchronization-breaking bugs.
I:HIntegrity impact, high: Concurrent unsynchronized callers can interleave `idpf_ptp_enable_shtime()` MMIO writes and cached PHC updates, corrupting device clock and driver timing state in ways that constitute exploitable integrity impact beyond a benign crash.
A:HAvailability impact, high: Taking an uninitialized spinlock during HW-reset recovery can cause kernel deadlock, oops, or hang (lockdep “non-static key” failure was observed in the fix commit’s HW-reset trace), satisfying high availability impact for kernel stability bugs.