CVE-2026-63803

hdlc_ppp: sync per-proto timers before freeing hdlc state

HIGH
7.8
CVSS Score
Published: July 19, 2026 at 12:02 PM UTC
Updated: October 19, 2026 at 08:19 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.1%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2.6.12.1 ≤ v < 5.10.2615.11 ≤ v < 5.15.2115.16 ≤ v < 6.1.1776.13 ≤ v < 6.18.386.19 ≤ v < 7.1.36.2 ≤ v < 6.6.1446.7 ≤ v < 6.12.951da177e4c3f41524e886b7f1b8a0c1fc7321cac22.6.122.6.12 rc22.6.12 rc32.6.12 rc42.6.12 rc5
Vendor states this is fixed in 508a0139d3bf60f6a03d2fbfb63a89a9463d983a (fixed)
Vendor states this is fixed in 5a84398101bf9f11e84b176343e4e3ba83e668c0 (fixed)
Vendor states this is fixed in 8308122bc9c065b1f376e081ed300129a2ac9545 (fixed)
Vendor states this is fixed in 86d80a231bde4cfb64bfbfbfffd83056fc93628f (fixed)
Vendor states this is fixed in a594debfd4e7ec39413647458907f689ef57fd2f (fixed)
Vendor states this is fixed in c64dbef1c0fbd36f9530aa75112acdf6a6d3cfd8 (fixed)
Vendor states this is fixed in c78a4e41ab5ead6193ad8a2dd92e8906bae659fa (fixed)
Vendor states this is fixed in ce8f9ddca0c9f217342a8b49efd309aa35b81a36 (fixed)
Vendor states this is fixed in 2.6.12 (unaffected)
Vendor states this is fixed in 5.10.261 (unaffected)
Vendor states this is fixed in 5.15.211 (unaffected)
Vendor states this is fixed in 6.1.177 (unaffected)
Vendor states this is fixed in 6.12.95 (unaffected)
Vendor states this is fixed in 6.18.38 (unaffected)
Vendor states this is fixed in 6.6.144 (unaffected)
Vendor states this is fixed in 7.1.3 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-416

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card