Linux Kernel PPP Unprivileged User-Namespace Precondition Probe — CVE-2026-53075

Metadata

Affected Target

Summary

This is a small local diagnostic probe, not a full weaponized exploit. It checks whether the preconditions for CVE-2026-53075 (an unprivileged-user attack path against the kernel ppp driver) are present on the running kernel: it creates an unprivileged user+network namespace via unshare(CLONE_NEWUSER | CLONE_NEWNET), writes a UID mapping so the calling user appears as root inside the new namespace, then attempts to open /dev/ppp and issue the PPPIOCNEWUNIT administrative ioctl from inside that sandbox. If the ioctl succeeds (or fails with an unexpected errno such as EFAULT/EINVAL/ENOTTY rather than EPERM/EACCES), the kernel failed to block a cross-namespace privileged operation, indicating the host is vulnerable.

Vulnerability Details

Root Cause

The kernel PPP driver’s PPPIOCNEWUNIT ioctl (and related administrative operations on /dev/ppp) can be reached by a process that is only “root” inside an unprivileged user namespace (created via unshare(CLONE_NEWUSER)), rather than genuine host-level privilege. If the ioctl path does not properly re-validate capabilities against the namespace in which the device was opened, an unprivileged local user can perform an operation that should require real privilege (CWE-284: Improper Access Control).

Attack Vector

1. As an unprivileged user, call unshare(CLONE_NEWUSER | CLONE_NEWNET) to enter a new user+network namespace, becoming virtual root (UID 0) inside it.
2. Write /proc/self/uid_map to map the sandbox’s UID 0 back to the real (unprivileged) UID.
3. Open /dev/ppp from inside the sandbox.
4. Issue the PPPIOCNEWUNIT ioctl; on a vulnerable kernel this succeeds or fails in a way that shows the privilege check was bypassed.

Impact

If the underlying kernel bug is present, an unprivileged local user could manipulate PPP network devices/state that should require elevated (root/CAP_NET_ADMIN)-equivalent privilege, which can be a stepping stone toward further local privilege escalation or denial of service. This probe only demonstrates the access-control precondition; it does not itself escalate to root.

Environment / Lab Setup

Target:   Linux host with the `ppp` kernel module/device (/dev/ppp) present
Attacker: Any unprivileged local user account, gcc toolchain to compile check_ppp.c

Proof of Concept

PoC Script

See check_ppp in this folder (C source, no file extension in upstream repo).

1
2

gcc -o check_ppp check_ppp
./check_ppp

Run as a normal (non-root) user. The program prints step-by-step diagnostics for the namespace creation, UID mapping, /dev/ppp open, and final ioctl call, then prints a verdict: “safe” (patched kernel) if the kernel rejects the operation with EPERM/EACCES, or a warning that the kernel is affected if the ioctl is allowed through.

Detection & IOCs

Signs of compromise:

• Unprivileged processes creating user namespaces (unshare/clone with CLONE_NEWUSER) and then opening /dev/ppp
• PPPIOCNEWUNIT ioctl calls originating from processes with non-root real UID
• Unexpected creation of new PPP network interfaces by non-privileged users

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/lottiedeyan/CVE-2026-53075poc on 2026-07-05. This is a precondition probe/diagnostic tool rather than a full privilege-escalation exploit chain — it verifies whether the unprivileged-namespace-to-/dev/ppp attack surface is reachable, but does not itself demonstrate a complete escalation to root. The upstream README consists only of two screenshots; no additional written details (author bio, CVSS, patch version) were provided beyond the source code itself.