https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:08:54 +0000 https://cve.radiocsirt.org/vuln/alsa-2026:57597 <p><strong>Affected:</strong> AlmaLinux:10: kbd, AlmaLinux:10: kbd-legacy, AlmaLinux:10: kbd-misc</p> <p>The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.</p> <p>Security Fix(es):</p> <p>* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)</p> <p>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.</p> <p><strong>Affected:</strong> AlmaLinux:10: kbd, AlmaLinux:10: kbd-legacy, AlmaLinux:10: kbd-misc</p> <p>The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.</p> <p>Security Fix(es):</p> <p>* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)</p> <p>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.</p> https://cve.radiocsirt.org/vuln/alsa-2026:57597 https://cve.radiocsirt.org/vuln/euvd-2026-368444 EUVD-2026-368444 https://cve.radiocsirt.org/vuln/euvd-2026-368444 https://cve.radiocsirt.org/vuln/fkie_cve-2026-72693 <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>`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://cve.radiocsirt.org/vuln/fkie_cve-2026-72693 https://cve.radiocsirt.org/vuln/ghsa-6766-cx7r-c5q6 <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>`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://cve.radiocsirt.org/vuln/ghsa-6766-cx7r-c5q6 https://cve.radiocsirt.org/vuln/msrc_cve-2026-72693 msrc_CVE-2026-72693 https://cve.radiocsirt.org/vuln/msrc_cve-2026-72693 https://cve.radiocsirt.org/vuln/oesa-2026-3505 <p><strong>Affected:</strong> 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</p> <p>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):</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(&amp;quot;/proc/&amp;lt;pid&amp;gt;/fd/0&amp;quot;)`. `stat()` on `/proc/&amp;lt;pid&amp;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)</p> <p><strong>Affected:</strong> 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</p> <p>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):</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(&amp;quot;/proc/&amp;lt;pid&amp;gt;/fd/0&amp;quot;)`. `stat()` on `/proc/&amp;lt;pid&amp;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)</p> https://cve.radiocsirt.org/vuln/oesa-2026-3505 https://cve.radiocsirt.org/vuln/opensuse-su-2026:21939-1 <p>Security update for kbd</p> <p>Security update for kbd</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21939-1 https://cve.radiocsirt.org/vuln/rhsa-2026:41136 <p>kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login</p> <p>kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login</p> https://cve.radiocsirt.org/vuln/rhsa-2026:41136 https://cve.radiocsirt.org/vuln/rlsa-2026:57597 <p><strong>Affected:</strong> Rocky Linux:10: kbd</p> <p>The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.</p> <p>Security Fix(es):</p> <p>* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)</p> <p>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.</p> <p><strong>Affected:</strong> Rocky Linux:10: kbd</p> <p>The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files.</p> <p>Security Fix(es):</p> <p>* kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693)</p> <p>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.</p> https://cve.radiocsirt.org/vuln/rlsa-2026:57597 https://cve.radiocsirt.org/vuln/suse-su-2026:23742-1 <p>Security update for kbd</p> <p>Security update for kbd</p> https://cve.radiocsirt.org/vuln/suse-su-2026:23742-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72693 <p><strong>Affected:</strong> 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</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> 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</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://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72693 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2961 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2961