https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 08:27:41 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72693 <p><strong>Affected:</strong> Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4.22, Red Hat Hardened Images, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat OpenShift Container Platform 4</p> <p>`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(&#34;/proc/&lt;pid&gt;/fd/0&#34;)`. `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. 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.</p> <p><strong>Affected:</strong> Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4.22, Red Hat Hardened Images, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat OpenShift Container Platform 4</p> <p>`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(&#34;/proc/&lt;pid&gt;/fd/0&#34;)`. `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. 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.</p> https://vulnerability.circl.lu/vuln/cve-2026-72693