Affected: AlmaLinux:10: kbd, AlmaLinux:10: kbd-legacy, AlmaLinux:10: kbd-misc

The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.

Security Fix(es):

* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

`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.

`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: openEuler:20.03-LTS-SP4: kbd, openEuler:22.03-LTS-SP4: kbd, openEuler:24.03-LTS-SP1: kbd, openEuler:24.03-LTS-SP3: kbd, openEuler:24.03-LTS-SP4: kbd

The project contains tools for managing Linux console ,including Linux console,virtual terminals, keyboard, etc, mainly, what they do is loading console fonts and keyboard maps. Security Fix(es):

`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(&quot;/proc/&lt;pid&gt;/fd/0&quot;)`. `stat()` on `/proc/&lt;pid&gt;/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.(CVE-2026-72693)

Security update for kbd

kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login

Affected: Rocky Linux:10: kbd

The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.

Security Fix(es):

* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Security update for kbd

Affected: Ubuntu:14.04:LTS: kbd, Ubuntu:16.04:LTS: kbd, Ubuntu:18.04:LTS: kbd, Ubuntu:20.04:LTS: kbd, Ubuntu:22.04:LTS: kbd, Ubuntu:24.04:LTS: kbd, Ubuntu:26.04:LTS: kbd

`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.

Ein Angreifer kann mehrere Schwachstellen in Red Hat Enterprise Linux ausnutzen, um seine Privilegien zu erhöhen, beliebigen Code auszuführen, Daten zu manipulieren oder offenzulegen und einen Denial-of-Service-Zustand auszulösen.