CVE-2026-63803

What it actually does

This is a Linux kernel use-after-free in the HDLC PPP protocol teardown path. PPP control protocol timers for LCP, IPCP, and IPV6CP can remain active or already executing while the associated HDLC state allocation is freed during device unregister or protocol re-attach. A timer callback that survives the free can later dereference freed kernel memory, including PPP state and locking structures. Because the flaw occurs in kernel memory, successful exploitation could cause kernel crash, memory corruption, privilege escalation, or arbitrary kernel-code execution, depending on exploitability on a specific kernel build and configuration.

Why it matters to the business

Systems that expose or use Linux HDLC PPP functionality are at risk of local privilege escalation or denial of service by a user or process with sufficient local privileges to manipulate the affected network protocol/device path. The practical risk is highest on systems where untrusted local users, containers, network-management services, or automation can configure HDLC/PPP interfaces. Although EPSS is currently low, the CVSS impact is high because a successful exploit can compromise the host operating system or crash it, affecting service availability and trust in the system.

How an attack unfolds

An attacker first obtains local access with permissions sufficient to interact with the affected Linux networking control path, such as configuring or reattaching an HDLC PPP protocol on a network device. The attacker then manipulates the PPP lifecycle so that one or more PPP control protocol timers are armed or executing while the HDLC PPP protocol state is detached. During unregister or re-attach, the kernel frees the HDLC state without synchronously shutting down all per-protocol timers. If a timer callback continues after the free and later accesses the freed PPP state or lock, the kernel dereferences stale memory. In the simplest case this produces a kernel oops or panic; with heap-shaping and reliable timing, an attacker may be able to turn the use-after-free into kernel memory corruption and elevate privileges.

How to fix it

Upgrade to a Linux kernel version that includes the hdlc_ppp fix adding a PPP detach handler that synchronously shuts down per-protocol timers with timer_shutdown_sync() before freeing HDLC state, and initializes those timers unconditionally at protocol attach time. If vendor packages are used, apply the relevant distribution kernel security update rather than attempting to patch the driver manually. Where immediate patching is not possible, reduce exposure by disabling or unloading unused HDLC/PPP-related kernel modules, restricting access to network administration capabilities, limiting untrusted local shell access, and ensuring containers or services do not receive CAP_NET_ADMIN unless strictly required. Treat mitigations as temporary because the root cause is kernel memory lifetime management.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the HDLC PPP timer teardown issue. Validate by checking the installed kernel package changelog/advisory for this CVE or for references to synchronizing PPP per-protocol timers before freeing HDLC state. On source-based kernels, verify that the HDLC PPP detach path calls a PPP-specific detach/release helper before kfree of hdlc state and that the helper uses timer_shutdown_sync() for each PPP control protocol timer. Confirm systems have rebooted into the fixed kernel, not merely installed it. Also inventory whether HDLC/PPP modules are present or loaded and whether local users or services have CAP_NET_ADMIN or equivalent ability to manipulate network protocol attachments.

Typical attack path

1. Gain local code execution on a Linux system running an affected kernel with HDLC PPP support available.
2. Obtain or abuse privileges needed to configure HDLC/PPP networking state, such as network administration capability or access through a privileged helper/service.
3. Attach PPP over HDLC and cause PPP control protocol timers such as LCP, IPCP, or IPV6CP to be initialized and armed.
4. Trigger protocol detach, device unregister, or protocol re-attach while a PPP timer callback is pending or executing.
5. Race the teardown path so the HDLC PPP state is freed before the timer callback fully completes.
6. Cause the stale timer callback to dereference freed kernel memory, leading to crash or exploitable kernel memory corruption.
7. If exploitation is reliable, use the memory corruption primitive to escalate privileges or execute code in kernel context.

How to detect it

Review kernel logs, system journals, crash dumps, and endpoint telemetry for evidence of kernel faults around HDLC PPP teardown, PPP timer callbacks, or unexpected network protocol reconfiguration. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, systemd journal kernel facility, kdump/vmcore artifacts, audit logs for privileged network configuration commands, and EDR telemetry showing use of ip, ifconfig, ioctl-heavy custom tools, or module manipulation. Look for sequences where HDLC/PPP devices are attached, detached, unregistered, or reattached shortly before a kernel oops, panic, general protection fault, KASAN use-after-free report, slab corruption warning, or lock/memory fault. Because exploitation is local and timing-dependent, absence of a clear IOC does not prove safety; repeated unexplained kernel crashes involving PPP/HDLC code should be treated as suspicious, especially on systems with untrusted local users or privileged containers. No public exploitation or KEV listing is currently indicated in the provided data, so detection should focus on crash forensics and anomalous local manipulation of HDLC/PPP functionality rather than known malware signatures.

• hdlc_ppp
• ppp_timer
• ppp_cp_event
• detach_hdlc_protocol
• unregister_hdlc_device
• attach_hdlc_protocol
• BUG: KASAN: use-after-free
• use-after-free in ppp_timer
• general protection fault
• kernel NULL pointer dereference
• slab-use-after-free
• kernel BUG at
• Oops:
• Call Trace:
• timer_shutdown_sync
• timer_delete
• LCP
• IPCP
• IPV6CP

What your security team should do

• Prioritize patching Linux systems that allow local user access, run multi-tenant workloads, grant CAP_NET_ADMIN to containers or services, or use HDLC/PPP networking features.
• Deploy the fixed vendor kernel and reboot affected systems to ensure the patched kernel is active.
• Temporarily remove or block unused HDLC/PPP kernel modules where operationally feasible.
• Audit privileged services, containers, and user roles for unnecessary network-administration permissions and remove CAP_NET_ADMIN where not required.
• Monitor kernel logs for crashes or warnings involving hdlc_ppp, PPP timers, use-after-free, slab corruption, or general protection faults.
• If suspicious crashes occurred before patching, preserve kernel logs, crash dumps, and package/version data for forensic review.
• Track vendor advisories for exact fixed kernel package versions because affected and fixed versions vary by distribution and backport policy.