Описание
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject userspace cifs.spnego descriptions
cifs.spnego key descriptions contain authority-bearing fields such as
pid, uid, creduid, and upcall_target that cifs.upcall treats as
kernel-originating inputs. However, userspace can also create keys of
this type through request_key(2) or add_key(2), allowing those fields to
be supplied without CIFS origin.
Only accept cifs.spnego descriptions while CIFS is using its private
spnego_cred to request the key.
A privilege escalation vulnerability was found in the Linux kernel's CIFS client implementation. This could allow a local attacker to impersonate other users, bypass authentication in SMB mount operations, and potentially gain unauthorized access to network file shares or escalate privileges.
Отчет
This issue is classified as Important severity primarily because a low-privileged local user can achieve full privilege escalation to root without any user interaction. The attack requires local access, which prevents remote exploitation and is the primary factor keeping the rating at Important rather than Critical.
Exploitation requires three components to be present on the system: the cifs kernel module (loaded or loadable), the cifs-utils package with its default cifs.spnego request-key rule, and the ability to create unprivileged user and mount namespaces. All three must be present for the attack chain to succeed. Environments that do not use SMB/CIFS file shares or Active Directory integration are unlikely to have cifs-utils installed, reducing their exposure.
In OpenShift Container Platform 4, this flaw is rated Low. The default restricted-v2 Security Context Constraint (SCC) sets allowPrivilegeEscalation: false on all pods, which causes the kernel to ignore setuid file bits, preventing privilege escalation. Under non-default SCCs such as anyuid that permit privilege escalation, the vulnerability is constrained by PID and mount namespace isolation to the container's own filesystem. An attacker would only be able to escalate privileges within the container, not on the host or across pods.
Меры по смягчению последствий
See the security bulletin for a detailed mitigation procedure.
Ссылки на источники
Дополнительная информация
Статус:
EPSS
7.8 High
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.
In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.
smb: client: reject userspace cifs.spnego descriptions
In the Linux kernel, the following vulnerability has been resolved: s ...
In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.
EPSS
7.8 High
CVSS3