CVE-2026-72693: Kbd: local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login

AIONLYREPORT package: kbd-2.8.0-3.fc43 ------ Summary: Local Privilege Escalation in openvt via Incorrect Process Owner Verification: openvt -u trusts the ownership of the TTY referenced by /proc/<pid>/fd/0 instead of the owning process, allowing passwordless root login in documented kbrequest/init deployments. Requirements to exploit: Local unprivileged access to a system where openvt -u is invoked with root privileges from a kbrequest/init configuration such as kb::kbrequest:/usr/bin/openvt -us, plus the ability to keep a process alive with fd 0 attached to the originating VT and then trigger the configured keyboard request. Component affected: kbd-2.8.0-3.fc43: src/openvt.c, authenticateuser(), and the privileged openvt -u login path. Version affected: kbd-2.8.0-3.fc43 when openvt -u is used in a privileged kbrequest/init deployment such as kb::kbrequest:/usr/bin/openvt -us Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - 7.8 (HIGH) AV:L - Exploitation requires local access to the affected host and an interactive VT/session. AC:L - In the affected deployment, exploitation is straightforward: keep a process attached to the VT, log out, and trigger the configured keyboard request. PR:L - The attacker needs only normal unprivileged local access. UI:N - No separate victim interaction is required; the attacker performs the triggering action directly. S:U - The vulnerable check and resulting privilege change occur within the same system security scope. C:H - Successful exploitation yields root access and exposure of system-wide data. I:H - Successful exploitation yields root authority to modify system state arbitrarily. A:H - Successful exploitation yields root authority to disrupt services or otherwise fully impact availability. Impact: Important. Red Hat rates flaws that allow a local user to gain additional privileges as Important. In the affected deployment, this issue can bypass normal authentication and yield root access through login -f. It is not Critical because exploitation is local and depends on a specific privileged configuration, but the resulting compromise is still full system compromise where that configuration is present. Embargo: no Reason: The issue is local-only and configuration-dependent, and there is a straightforward operational workaround: stop using openvt -u in the kbrequest/init path or disable the keyboard request binding until a fix is available. Acknowledgement: Aisle Research Vulnerability Details: 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 authenticateuser() relies on stat("/proc/<pid>/fd/0"): c while ((dentp = readdir(dp))) { sprintf(filename, "/proc/%s/fd/0", dentp->dname); if (stat(filename, &buf)) continue; if (buf.stdev == consoledev && buf.stino == consoleino && buf.stuid == consoleuid) goto gotaprocess; } stat() on /proc/<pid>/fd/0 follows the symlink to the underlying TTY device node. As a result, buf.stuid 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: c if (asuser) execlp("login", "login", "-f", username, NULL); 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. Steps to reproduce: 1. Configure the documented init usage with kb::kbrequest:/usr/bin/openvt -us. 2. Load a keyboard mapping such as echo "alt keycode 103 = SpawnConsole" loadkeys. 3. Log in as an unprivileged user on tty1. 4. Start a background process that keeps standard input attached to that TTY: nohup sh -c 'sleep 1000000' </dev/tty1 >/dev/null 2>&1 &. 5. Log out from tty1 so the TTY ownership returns to root or the getty owner. 6. Trigger the configured keyboard request, for example with Alt+Up Arrow in the documented setup. 7. Observe passwordless login -f root execution on the new VT. Mitigation: Until a fix is available, avoid openvt -u in privileged kbrequest/init deployments. If console spawning is required, configure the keyboard request to start a normal authenticated login on the new VT instead of pre-authenticating with login -f, or disable the keyboard request binding entirely. Proposed Fix: Validate the actual process owner from /proc/<pid> before matching its fd/0 against the target TTY, and stop using the TTY node owner as proof of process ownership. diff diff --git a/src/openvt.c b/src/openvt.c — a/src/openvt.c +++ b/src/openvt.c @@ -120,13 +120,21 @@ authenticateuser(int curvt) / check to make sure that user has a process on that tty / / this will fail for example when X is running on the tty / while ((dentp = readdir(dp))) { + struct stat pbuf; + + sprintf(filename, "/proc/%s", dentp->dname); + if (stat(filename, &pbuf)) + continue; + if (pbuf.stuid != consoleuid) + continue; + sprintf(filename, "/proc/%s/fd/0", dentp->dname); - if (stat(filename, &buf)) continue; if (buf.stdev == consoledev && buf.stino == consoleino && buf.stuid == consoleuid) + if (buf.stdev == consoledev && buf.stino == consoleino) goto gotaprocess; }

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat

Kbd: local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login

— Microsoft