CVE-2026-53262: Linux Kernel L2TP Use-After-Free Privilege Escalation

Technical summary

The vulnerability resides in pppol2tp_ioctl(), which directly dereferences sock->sk->sk_user_data without acquiring a reference or holding appropriate locks. During copy_from_user() operations, an attacker can induce a controllable sleep (e.g., via userfaultfd page fault handling). Concurrently, a socket close triggers pppol2tp_session_close(), which enqueues l2tp_session_del_work to free the session structure. When the ioctl resumes, it operates on a stale, freed pointer—a classic use-after-free. The fix wraps session access with pppol2tp_sock_to_session(), an RCU-safe refcounted helper that increments the session's reference count for the duration of the ioctl. All return paths guarantee l2tp_session_put() is called to decrement the reference, ensuring safe cleanup. Session validation is performed only for L2TP-specific ioctls, allowing unconnected sockets to return -ENOIOCTLCMD as expected.

Business impact

Exploitation enables a local, unprivileged user to crash the kernel or potentially escalate privileges. Systems running affected kernel versions with L2TP networking enabled are at risk. The impact is highest in multi-tenant or shared-system environments where untrusted local users have account access. Virtual machines, containers, and shared hosting platforms should be prioritized for patching. Services relying on L2TP for VPN or tunneling may experience denial of service.

Affected systems

All Linux kernel versions with the L2TP pppol2tp module are affected. The vulnerability has been identified in the mainline kernel; users should verify which specific kernel releases include the patch by consulting the Linux kernel security advisories and their distribution's patch status. Kernels with L2TP built-in or loaded as a module are at risk; systems without L2TP support are unaffected.

Exploitability

Exploitation requires local code execution and the ability to invoke socket ioctl operations. The attacker must coordinate timing between userfaultfd-induced sleep and concurrent socket close, which is technically complex but achievable. The vulnerability does not require elevated privileges at the moment of exploitation, though the consequences may grant elevated capabilities. Public exploit code is not yet widely available, but the technique is within reach of skilled attackers.

Remediation

Apply the kernel patch that introduces proper reference counting via pppol2tp_sock_to_session() and ensures all return paths in pppol2tp_ioctl() call l2tp_session_put(). This fix is available in upstream Linux kernel repositories. Contact your distribution vendor for backported patches or compile a patched kernel version. Distributions have begun releasing kernel updates; check your vendor's security advisory for specific version numbers.

Patch guidance

Obtain the patched kernel version from your Linux distribution's security repository (Red Hat, Debian, Ubuntu, SUSE, etc.). Most distributions will issue kernel security advisories with specific patched versions. For systems running kernel.org vanilla kernels, pull the fix from the mainline kernel source tree (commit hash available in upstream security advisories). After patching, reboot to activate the new kernel. Verify the fix by checking your kernel version and build information post-reboot.

Detection guidance

Monitor system logs for kernel BUG messages, NULL pointer dereference warnings, or general protection faults (GPF) related to l2tp or pppol2tp modules. Tools like auditd can log ioctl syscalls on L2TP sockets to identify suspicious patterns. Kernel address sanitizer (KASAN) or KSMEM builds will detect the UAF with greater fidelity in test environments. Network-based detection is limited; focus on host-level monitoring. Check loaded kernel modules with lsmod to confirm pppol2tp presence.

Why prioritize this

This is a HIGH severity local privilege escalation vulnerability affecting a core kernel subsystem. The CVSS 3.1 score of 7.8 reflects high confidentiality, integrity, and availability impact with low attack complexity. Although exploitation requires local access, the barrier to success is moderate for informed attackers. Systems in production should prioritize patching within their standard kernel update cycle, typically 1–2 weeks for critical updates. Shared hosting, multi-tenant systems, and containers warrant accelerated patching.

Risk score, explained

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) assigns HIGH severity based on: (1) Local attack vector—requires local code execution; (2) Low attack complexity—the exploit technique is straightforward once access is gained; (3) Low privileges required—an unprivileged user can trigger it; (4) No user interaction—the attack is fully automated; (5) Unchanged scope—impact is limited to the affected system; (6) High confidentiality, integrity, and availability impact—successful exploitation can read memory, corrupt data, or crash the system. The score reflects significant risk to affected systems, particularly those with multi-user access or untrusted workloads.

Frequently asked questions