Skip to main content

Linux Kernel CVE-2026-53075

| EUVDEUVD-2026-38943 HIGH
2026-06-24 Linux GHSA-v495-j4w2-68hc
Information Disclosure Linux Red Hat Suse
8.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
8.7 HIGH

Local unprivileged user (PR:L) needs only userns creation (AC:L); crossing into an inherited netns is a scope change (S:C); impact is mainly network admin control (I:H/A:H) with limited direct data disclosure (C:L).

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:L/SI:L/SA:L
SUSE
6.1 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 09:04 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
8.8 (HIGH)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:30 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 24, 2026 - 16:30 cve.org
HIGH 8.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

ppp: require CAP_NET_ADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns.

As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

AnalysisAI

Local privilege escalation in the Linux kernel's PPP driver allows an unprivileged user to issue network-administration ioctls against a network namespace they should not control. The /dev/ppp device authorizes opens against the file owner's user namespace (f_cred->user_ns) while unattached administrative ioctls act on current->nsproxy->net_ns, so a user who creates a new user namespace via CLONE_NEWUSER and gains CAP_NET_ADMIN only there can still invoke PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited (parent) network namespace. No public exploit identified at time of analysis, and EPSS is low (0.26%, 17th percentile), indicating no current evidence of mass exploitation.

Technical ContextAI

The flaw lives in the PPP (Point-to-Point Protocol) subsystem of the Linux kernel, exposed through the /dev/ppp character device. The root cause is a namespace-authorization mismatch: permission for the device is checked against the user namespace recorded in the file credentials at open time, but the unattached administrative ioctl handlers (unit creation and channel/unit attach) operate on the caller's current network namespace. Because CAP_NET_ADMIN is evaluated in the wrong user namespace, a capability legitimately held only inside a freshly created user namespace is incorrectly honored for operations targeting an inherited network namespace. This is a CWE-269 / CWE-863 class issue (improper privilege management / incorrect authorization across user-namespace and network-namespace boundaries), a recurring pattern in kernel code that mixes f_cred-based and current-task-based capability checks. The official CWE field is N/A in the source data. The fix requires CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls, preserving normal pppd operation in the netns where it is actually privileged.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 5.10.258, 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33, 7.0.10, or 7.1, or the corresponding patched build from your distribution. The upstream fixes are available as kernel.org stable commits (https://git.kernel.org/stable/c/c9edd90c57ae23692fff6b049fdfa4572a9fd532 and the parallel backports 5080e188c914110034bbc569d5cfa2f06204681d, 67e901e28d177ac9a9bed76d69ce3471e704a89e, 954745d0223e7caec917c0b2d1a889ff56fa6e54, 3b2c2157dc2afc5c17cd7238afefca92f1ef330e, 5013be175c7ffd8b39efbc3c9c4db5b10b85fea8, 1a8a51ce85075a56a743b6f142606dd2696a391c, 2bb6379416fd19f44c3423a00bfd8626259f6067). Where patching must be deferred, the most effective compensating control is to disable unprivileged user namespaces (sysctl kernel.unprivileged_userns_clone=0 on Debian/Ubuntu, or user.max_user_namespaces=0), which removes the CLONE_NEWUSER primitive the attack relies on - trade-off: this can break rootless containers, sandboxed browsers (Chrome/Firefox sandbox), and some CI tooling. Alternatively, restrict access to /dev/ppp via permissions/device cgroup so untrusted local users cannot open it (trade-off: breaks legitimate non-root pppd usage), and avoid handing CAP_NET_ADMIN or PPP access to untrusted tenants on shared hosts.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.177 Container suse/sl-micro/6.1/base-os-container:2.2.1-5.155 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.206 Container suse/sl-micro/6.1/rt-os-container:2.2.1-5.152 Affected
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected

Share

CVE-2026-53075 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy