`openvt -u` is intended to identify the owner of the current VT and then execute `login` as that user from a privileged context. In the documented `kbrequest`/init usage, the ownership test in `authenticate_user()` relies on `stat("/proc/<pid>/fd/0")`. `stat()` on `/proc/<pid>/fd/0` follows the symlink to the underlying TTY device node. As a result, `buf.st_uid` reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to `root` or the getty owner after logout while an unprivileged process still has `fd 0` attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the `-u` path executes a passwordless login as the selected user. In the documented `kbrequest`/init deployment using `openvt -us`, this can result in passwordless `login -f root` on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use `openvt -u` from a privileged `kbrequest`/init path.
Metrics
Affected Vendors & Products
References
History
Tue, 11 Aug 2026 09:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | `openvt -u` is intended to identify the owner of the current VT and then execute `login` as that user from a privileged context. In the documented `kbrequest`/init usage, the ownership test in `authenticate_user()` relies on `stat("/proc/<pid>/fd/0")`. `stat()` on `/proc/<pid>/fd/0` follows the symlink to the underlying TTY device node. As a result, `buf.st_uid` reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to `root` or the getty owner after logout while an unprivileged process still has `fd 0` attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the `-u` path executes a passwordless login as the selected user. In the documented `kbrequest`/init deployment using `openvt -us`, this can result in passwordless `login -f root` on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use `openvt -u` from a privileged `kbrequest`/init path. | |
| Title | Kbd: local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login | |
| First Time appeared |
Redhat
Redhat enterprise Linux Redhat hummingbird Redhat openshift |
|
| Weaknesses | CWE-284 | |
| CPEs | cpe:/a:redhat:hummingbird:1 cpe:/a:redhat:openshift:4 cpe:/o:redhat:enterprise_linux:10 cpe:/o:redhat:enterprise_linux:6 cpe:/o:redhat:enterprise_linux:7 cpe:/o:redhat:enterprise_linux:8 cpe:/o:redhat:enterprise_linux:9 |
|
| Vendors & Products |
Redhat
Redhat enterprise Linux Redhat hummingbird Redhat openshift |
|
| References |
| |
| Metrics |
cvssV3_1
|
Status: PUBLISHED
Assigner: redhat
Published:
Updated: 2026-08-11T08:39:24.983Z
Reserved: 2026-08-10T12:35:16.746Z
Link: CVE-2026-72693
No data.
No data.
No data.
OpenCVE Enrichment
Updated: 2026-08-11T10:30:04Z