Описание
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.
Отчет
A flaw was found in openvt (part of the kbd package) where incorrect process owner verification can allow a local unprivileged attacker to achieve passwordless root login. However, exploitation requires a non-default kbrequest/init configuration that explicitly invokes openvt -u, combined with a specific timing condition where TTY ownership has returned to root after logout while an unprivileged process still holds an open file descriptor to the TTY. This combination of prerequisites — a deliberately configured kbrequest/init setup and a narrow TTY-state race — is not present in standard Red Hat product deployments. For this reason, Red Hat rates the impact of this vulnerability as Moderate despite the high CVSS base score, which reflects only the technical worst-case impact and not the real-world exploitation constraints.
Меры по смягчению последствий
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.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kbd | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kbd | Affected | ||
| Red Hat Enterprise Linux 8 | kbd | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Affected | ||
| Red Hat Enterprise Linux 10 | kbd | Fixed | RHSA-2026:57597 | 20.08.2026 |
| Red Hat Enterprise Linux 9 | kbd | Fixed | RHSA-2026:57610 | 20.08.2026 |
| Red Hat Hardened Images | kbd-main-2.10.0-2.hum1 | Fixed | RHSA-2026:41136 | 16.07.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
7.8 High
CVSS3
Связанные уязвимости
`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 depl...
`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 deploym
Kbd: local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login
`openvt -u` is intended to identify the owner of the current VT and th ...
EPSS
7.8 High
CVSS3