CVE-2026-97963: net: stmmac: initialize ptp_lock at probe time
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: initialize ptplock at probe time
priv->ptplock is only initialized in stmmacptpregister(), which runs during stmmacopen(). However, the lock is also used while the interface is down and has never been opened: tctaprioconfigure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmacgettime() takes priv->ptplock. Using an uninitialized rwlock is undefined behaviour. Move the rwlockinit() to stmmacdvrprobe(), together with the other private locks, so that ptplock is always valid regardless of the interface state.
Affected Software
Event History
Frequently Asked Questions
When can this issue be triggered?
It can be triggered when a TAPRIO schedule is configured for hardware offload while the affected stmmac network interface is down and has never been opened. In that state, TAPRIO invokes the PTP gettime64 callback, which uses ptp_lock before it has been initialized.
Are systems using the stmmac driver affected during normal interface operation?
The described unsafe path specifically requires the interface to be down and never previously opened. Opening the interface causes stmmac_ptp_register() to initialize ptp_lock, but relying on that prior state does not address the affected configuration path.
What is the practical consequence of triggering the issue?
The driver attempts to take an uninitialized rwlock, which is undefined behavior. The supplied information does not specify a further impact such as a crash, privilege escalation, or information disclosure.
What can be done if the fix cannot be applied immediately?
Avoid configuring TAPRIO hardware offload schedules on an stmmac interface while it is down and has never been opened. Bringing the interface up first initializes the lock in the existing code path, although updating to code that initializes the lock at probe time is the intended fix.