CVE-2026-80991
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A timing bug in a Linux network driver can let someone who is already logged in crash the computer or take control of it.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
A local use-after-free in the Linux kernel Renesas Ethernet AVB (ravb) PTP path lets ravb_ptp_interrupt() call ptp_clock_event() on a clock object that ravb_ptp_stop() is concurrently unregistering and freeing. The race can corrupt kernel memory, producing an oops/panic or, if the freed object is reused, arbitrary kernel read/write with full confidentiality, integrity, and availability impact (CVSS 7.8, AV:L/PR:L).
Why it matters to the business
Linux systems using the ravb driver can suffer unexpected kernel crashes (outage of networking and the host) or complete OS takeover by a logged-in low-privileged user. The issue is not in CISA KEV, has no reported ransomware use, and has no public exploit 20 days after publication, but shared, multi-tenant, or developer hosts with untrusted local users remain at risk of privilege escalation until kernels that serialize PTP clock teardown are deployed.
How an attack unfolds
An attacker who already has a local unprivileged account on a host with the ravb driver and PTP enabled induces overlapping PTP interrupt handling and PTP clock teardown (interface down, driver unload, or PTP stop). If the interrupt handler still holds the old clock pointer while unregister frees it, the resulting use-after-free can panic the kernel or be turned into kernel-memory corruption and local privilege escalation. Exploitation is local-only, race-dependent, and there are no named threat actors or public exploits associated with this flaw.
How to fix it
Apply a Linux kernel update that includes the ravb PTP teardown serialization fix (lockless READ_ONCE/WRITE_ONCE on the clock pointer, xchg() detach before disabling PTP interrupts, IRQ synchronization before ptp_clock_unregister). Track distribution and stable-kernel advisories for CVE-2026-80991 because no product-specific fixed versions were supplied. Until patched, restrict unprivileged local login and the ability to unload or reconfigure the ravb interface, and disable ravb PTP if the platform does not require it.
How to confirm the fix worked
Confirm the running kernel changelog or distro package includes the ravb PTP teardown serialization commit; lsmod/sysfs should still show ravb only if the hardware requires it, and the installed kernel version must match the patched package. After upgrade, reboot onto the new kernel, reproduce PTP enable/disable and interface down/up under load, and verify dmesg/journalctl show no ravb/ptp oops. Hosts without the ravb driver loaded are not exposed.
Typical attack path
- Obtain local unprivileged access to a Linux host whose Ethernet stack uses the ravb driver with PTP enabled
- Generate PTP-related interrupt activity while concurrently triggering PTP clock stop or driver teardown
- Win the race so ravb_ptp_interrupt() uses a clock pointer that is being unregistered and freed
- Cause kernel memory corruption via the use-after-free (panic for denial of service, or further corruption for privilege gain)
- If corruption is controlled, escalate to root or kernel equivalent and persist or move laterally from the compromised host
How to detect it
There is no public exploit and no associated threat-actor activity, so prior compromise is unlikely to leave a unique implant signature. Hunt kernel logs (dmesg, journalctl -k, crash dumps, pstore) around PTP stop, interface down, or ravb unload for oops/panic/use-after-free traces in ravb_ptp_interrupt, ravb_ptp_stop, ptp_clock_event, or ptp_clock_unregister. Correlate with local sessions, unexpected module unloads, and NIC reconfiguration. A clean boot with no such traces does not prove the race was never hit, but those stacks are the primary forensic artifact if exploitation or an accidental crash occurred.
- ravb_ptp_interrupt
- ravb_ptp_stop
- ptp_clock_unregister
- ptp_clock_event
- Unable to handle kernel paging request
- use-after-free
What your security team should do
- Inventory Linux hosts for the ravb module and PTP use, and prioritize patching those with untrusted local users
- Deploy vendor or distro kernels that contain the ravb PTP clock teardown serialization fix and reboot
- Until patched, limit local unprivileged access and block unprivileged interface/driver teardown on ravb NICs
- Alert on kernel oops/panic stacks mentioning ravb_ptp_interrupt, ravb_ptp_stop, ptp_clock_event, or ptp_clock_unregister
- Reassess after patching; this CVE is not KEV and has no known in-the-wild exploit, so treat residual risk as local LPE/DoS rather than mass remote compromise
The record
In the Linux kernel, the following vulnerability has been resolved: net: ravb: serialize PTP clock teardown ravb_ptp_interrupt() can race with ravb_ptp_stop() and pass the clock to ptp_clock_event() while ptp_clock_unregister() is freeing it. This can lead to a use-after-free. Use READ_ONCE() and WRITE_ONCE() for lockless access to the clock pointer. Atomically detach it with xchg() before disabling PTP interrupts, then synchronize all IRQs which can invoke ravb_ptp_interrupt() before unregistering the detached clock. A handler which read the old pointer completes before the clock is unregistered, while later handlers read NULL and skip the event.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|