`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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 1
- First seenCVSS 7.8NVD modified 2026-10-09 04:18
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 8
- https://access.redhat.com/errata/RHSA-2026:41136
- https://access.redhat.com/errata/RHSA-2026:57597
- https://access.redhat.com/errata/RHSA-2026:57610
- https://access.redhat.com/errata/RHSA-2026:60440
- https://access.redhat.com/errata/RHSA-2026:66357
- https://access.redhat.com/errata/RHSA-2026:78951
- https://access.redhat.com/security/cve/CVE-2026-72693
- https://bugzilla.redhat.com/show_bug.cgi?id=2462115