CVE-2026-53075: Linux Kernel PPP Driver Privilege Escalation via User Namespace Confusion

Technical summary

The PPP driver's authorization model was inconsistent across two code paths. The open operation checks capabilities against file->f_cred->user_ns, while unattached administrative ioctls (PPPIOCNEWUNIT, PPPIOCATTACH, PPPIOCATTCHAN) operate on current->nsproxy->net_ns without validating the caller's privilege in the owning user namespace. This permits a user to call clone(CLONE_NEWUSER) to create a new user namespace, elevate to CAP_NET_ADMIN within that isolated namespace, and then invoke PPP ioctls targeting the inherited parent network namespace, where the attacker holds no actual privileges. The fix requires CAP_NET_ADMIN to be held in the user namespace that owns the target network namespace, aligning authorization checks across both paths and preventing namespace-confusion attacks.

Business impact

Organizations running multi-tenant containerized or virtualized Linux workloads face potential disruption and privilege escalation. An attacker with local shell access could reconfigure or create PPP interfaces in the host or other tenant network namespaces, leading to network isolation bypasses, man-in-the-middle positioning, or denial of service. In cloud and shared-hosting environments where user namespace isolation is relied upon for multi-tenancy, this becomes a container-escape vector. For critical network infrastructure or high-availability systems using PPP links, unexpected reconfiguration could cause service outages. The high CVSS reflects the confluence of local access requirement with broad system-scope impact (scope change) and the ability to compromise confidentiality, integrity, and availability simultaneously.

Affected systems

All Linux kernel versions are affected prior to the patch being applied. The vulnerability specifically impacts systems where: (1) PPP support is compiled into the kernel or loaded as a module; (2) unprivileged users have access to /dev/ppp; and (3) user namespace and network namespace isolation features are enabled (common in containerized deployments and modern distributions). Standard desktop and server deployments with PPP configured for dial-up, VPN, or point-to-point links are at risk. The issue does not affect systems where PPP is disabled, where file system permissions prevent unprivileged /dev/ppp access, or where user namespaces are unavailable.

Exploitability

Exploitation requires local access and the ability to create user namespaces, which is available to unprivileged users on most modern distributions by default. The attack is straightforward: spawn a new user namespace, acquire CAP_NET_ADMIN within it, and issue ioctls. No race conditions, no complex state setup, no user interaction needed. The barrier to weaponization is low. However, the usefulness of the attack depends on network configuration—an attacker must know or discover which PPP units exist and what benefit reconfiguring them provides. Real-world impact in traditional single-tenant systems is limited, but in container and Kubernetes environments where network policy and namespace boundaries are security controls, this is a direct privilege escalation and isolation bypass.

Remediation

Apply the kernel patch that enforces CAP_NET_ADMIN checks in the user namespace owning the target network namespace for PPPIOCNEWUNIT, PPPIOCATTACH, and PPPIOCATTCHAN ioctls. This brings the unattached ioctl path into alignment with the /dev/ppp open path. The fix is transparent to legitimate pppd usage in its native privilege context and does not require configuration changes. Users should verify the patch version against their kernel's release notes and stable update branches. For systems where PPP is optional, disabling the driver entirely eliminates the attack surface.

Patch guidance

Verify the kernel version and branch against upstream Linux stable releases and your distribution's kernel security advisories. Patches will be released through standard kernel update mechanisms (e.g., linux-image packages on Debian/Ubuntu, kernel packages on RHEL/CentOS, or via pull requests to stable branches). Apply kernel updates as they become available from your vendor. Test in a non-production environment first, particularly if custom PPP configurations are in use. No manual code patching is required for end users; standard kernel update procedures apply.

Detection guidance

Monitor for suspicious ioctl calls against /dev/ppp. Use auditd rules to log CAP_NET_ADMIN capability checks and PPP ioctl invocations, especially from unprivileged processes. Check for processes creating new user namespaces followed by PPP operations. In containerized environments, audit pod and container escape attempts that involve namespace manipulation. Log file system access to /dev/ppp and correlation with namespace creation events (unshare, clone with CLONE_NEWUSER flags). Behavioral signals include rapid or repeated failed ioctl attempts and namespace creation by typically non-container-runtime processes.

Why prioritize this

This is a HIGH-severity privilege escalation and isolation bypass in a core kernel subsystem. While exploitation requires local access, the barrier is minimal and the scope change (affecting host and other namespaces) elevates impact significantly. In containerized and multi-tenant deployments, this directly undermines namespace-based isolation guarantees. Organizations relying on user namespaces for container security or sandbox isolation should treat this as urgent. Conversely, traditional single-tenant systems or those without PPP enabled can deprioritize relative to network-reachable vulnerabilities, but should still apply updates in normal maintenance cycles.

Risk score, explained

CVSS 8.8 (HIGH) reflects: local attack vector (AV:L, no network reach required but not zero-day remote); low attack complexity (AC:L, basic namespace operations available to all users); low privilege requirement (PR:L, unprivileged account suffices); no user interaction (UI:N); and crucially, scope change (S:C, impact extends beyond the attacker's isolation boundary to the host/other namespaces). Confidentiality, integrity, and availability are all compromised (C:H, I:H, A:H) through network reconfiguration and DoS potential. The alignment with privilege escalation, lateral movement, and container-escape patterns justifies the high end of the local-access severity spectrum.

Frequently asked questions