REDHAT-BUG-2492295: Medium severity Linux Linux kernel vulnerability
In the Linux kernel, the following vulnerability has been resolved:
ppp: require CAPNETADMIN in target netns for unattached ioctls
/dev/ppp open is currently authorized against file->fcred->userns, while unattached administrative ioctls operate on current->nsproxy->netns.
As a result, a local unprivileged user can create a new user namespace with CLONENEWUSER, gain CAPNETADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.
Require CAPNETADMIN 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.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
A local unprivileged user who can create a new user namespace with CLONE_NEWUSER can gain CAP_NET_ADMIN in that namespace and use it against an inherited network namespace.
Which PPP operations are affected?
The affected unattached administrative ioctls are PPPIOCNEWUNIT, PPPIOCATTACH, and PPPIOCATTCHAN.
What condition makes a system vulnerable?
The issue arises when /dev/ppp access is authorized using credentials from a new user namespace, while the administrative ioctl operates on an inherited network namespace. The vulnerable case is having CAP_NET_ADMIN only in the new user namespace rather than in the user namespace that owns the target network namespace.
What behavior does the fix enforce?
The fix requires CAP_NET_ADMIN in the user namespace that owns the target network namespace before unattached PPP administrative ioctls are processed. Normal pppd operation remains allowed in the network namespace where it is actually privileged.