CVE-2026-72693
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
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.
Affected Software
| Vendor | Product | Version Range | Status |
|---|
Weaknesses
- CWE-284: Improper Access Control
Workarounds
To mitigate this issue, avoid using openvt -u in privileged kbrequest/init deployments. Instead, configure the keyboard request to initiate a standard authenticated login on the new virtual terminal, or disable the keyboard request binding entirely until a fix is available. Changes to kbrequest configurations may require a system restart or service reload to take effect.
ADP Enrichment
CISA ADP Vulnrichment
- SSVC:
- Exploitation: none
- Automatable: no
- Technical Impact: total
References
- https://access.redhat.com/security/cve/CVE-2026-72693
- https://bugzilla.redhat.com/show_bug.cgi?id=2462115
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.