CVE-2025-37814: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT This requirement was overeagerly loosened in commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as it turns out, (1) the logic I implemented there was inconsistent (apologies!), (2) TIOCL_SELMOUSEREPORT might actually be a small security risk after all, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN already. In more detail: 1. The previous patch has inconsistent logic: In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), we checked for sel_mode == TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of this "mode" parameter were actually used as an additional way to pass an argument. So the patch did actually still require CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not require it if none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same policies for using TIOCL_SELMOUSEREPORT independent of the value of the "hidden" mouse button argument. I sent a separate documentation patch to the man page list with more details on TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can let an attacker simulate "keyboard" input to command line applications on the same terminal, like TIOCSTI and some other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports through TIOCL_SELMOUSEREPORT, an attacker can simulate mouse movements on the same terminal, similar to the TIOCSTI keystroke injection attacks that were previously possible with TIOCSTI and other TIOCL_SETSEL selection modes. Many programs (including libreadline/bash) are then prone to misinterpret these mouse reports as normal keyboard input because they do not expect input in the X11 mouse protocol form. The attacker does not have complete control over the escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape sequence. I went into more detail on that in the discussion at https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ It is not equally trivial to simulate arbitrary keystrokes as it was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")), but the general mechanism is there, and together with the small number of existing legit use cases (see below), it would be better to revert back to requiring CAP_SYS_ADMIN for TIOCL_SELMOUSEREPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or Consolation), and they are the only legit use case: To quote console_codes(4): The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it would be difficult to find good reasons for doing that, given that it would interfere with the reports that GPM is sending. More information on the interaction between GPM, terminals and th ---truncated---
AI Analysis
Technical Summary
CVE-2025-37814 is a vulnerability in the Linux kernel related to the handling of the TIOCL_SELMOUSEREPORT ioctl command within the tty subsystem. This ioctl is used to enable mouse reporting on virtual terminals, primarily intended for mouse daemons such as GPM (General Purpose Mouse) or Consolation, which run with CAP_SYS_ADMIN privileges. Previously, a patch (commit 2f83e38a095f) had loosened the requirement for CAP_SYS_ADMIN for some TIOCL_SETSEL modes, including TIOCL_SELMOUSEREPORT, but this was done with inconsistent logic. Specifically, the patch failed to consider that the lower four bits of the mode parameter could carry additional arguments, leading to a scenario where TIOCL_SELMOUSEREPORT could be invoked without CAP_SYS_ADMIN if no mouse button bits were set. This inconsistency introduced a security risk. The core risk arises because TIOCL_SELMOUSEREPORT allows injecting mouse reports into the terminal input stream. Attackers with access to this ioctl could simulate mouse movements and clicks, which many terminal applications (including libreadline and bash) might misinterpret as legitimate keyboard input due to their handling of X11 mouse protocol escape sequences. While this injection is less powerful than the previously known TIOCSTI ioctl (which allowed arbitrary keystroke injection), it still enables partial input simulation that could be exploited for command injection or privilege escalation on the same terminal session. The vulnerability was addressed by reverting the requirement that all uses of TIOCL_SELMOUSEREPORT require CAP_SYS_ADMIN, restoring the original security posture. This change ensures that only trusted processes (like mouse daemons running with administrative capabilities) can use this ioctl, mitigating the risk of unauthorized input injection. This vulnerability highlights the subtle security implications of ioctl permissions and the importance of strict capability checks in kernel interfaces that interact with user input streams.
Potential Impact
For European organizations, especially those running Linux servers or workstations with virtual terminals and mouse daemons, this vulnerability could allow local attackers or compromised low-privilege users to inject input events into terminal sessions. This could lead to unauthorized command execution, privilege escalation, or disruption of terminal-based workflows. Organizations relying on Linux for critical infrastructure, development environments, or terminal-based applications could face increased risk of insider threats or lateral movement within networks. While remote exploitation is unlikely without prior access, the vulnerability could be leveraged in multi-user systems, shared hosting environments, or containerized setups where terminal access is shared or exposed. The partial input injection capability may bypass some input validation or logging mechanisms, complicating detection and response. Given the widespread use of Linux across European industries, including finance, manufacturing, and public sector, the vulnerability poses a moderate risk that requires timely patching to prevent exploitation.
Mitigation Recommendations
1. Apply the official Linux kernel patch that reinstates the CAP_SYS_ADMIN requirement for TIOCL_SELMOUSEREPORT to ensure only trusted processes can invoke this ioctl. 2. Audit and restrict access to terminal devices and ensure that only necessary processes run with CAP_SYS_ADMIN capabilities. 3. Monitor and limit the use of mouse daemons like GPM or Consolation to trusted environments; disable or remove them if not required. 4. Implement strict user privilege separation and avoid granting unnecessary capabilities to untrusted users or processes. 5. Employ terminal input monitoring and anomaly detection to identify unusual mouse or keyboard input sequences that could indicate exploitation attempts. 6. Educate system administrators about the risks of ioctl misuse and encourage regular kernel updates. 7. For environments using containerization or virtualization, ensure that container privileges do not allow unauthorized ioctl access to host terminals. 8. Review and harden terminal application configurations (e.g., bash, libreadline) to handle unexpected input sequences more securely, if possible.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Italy, Spain, Poland, Belgium, Finland
CVE-2025-37814: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT This requirement was overeagerly loosened in commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as it turns out, (1) the logic I implemented there was inconsistent (apologies!), (2) TIOCL_SELMOUSEREPORT might actually be a small security risk after all, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN already. In more detail: 1. The previous patch has inconsistent logic: In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), we checked for sel_mode == TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of this "mode" parameter were actually used as an additional way to pass an argument. So the patch did actually still require CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not require it if none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same policies for using TIOCL_SELMOUSEREPORT independent of the value of the "hidden" mouse button argument. I sent a separate documentation patch to the man page list with more details on TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can let an attacker simulate "keyboard" input to command line applications on the same terminal, like TIOCSTI and some other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports through TIOCL_SELMOUSEREPORT, an attacker can simulate mouse movements on the same terminal, similar to the TIOCSTI keystroke injection attacks that were previously possible with TIOCSTI and other TIOCL_SETSEL selection modes. Many programs (including libreadline/bash) are then prone to misinterpret these mouse reports as normal keyboard input because they do not expect input in the X11 mouse protocol form. The attacker does not have complete control over the escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape sequence. I went into more detail on that in the discussion at https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ It is not equally trivial to simulate arbitrary keystrokes as it was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")), but the general mechanism is there, and together with the small number of existing legit use cases (see below), it would be better to revert back to requiring CAP_SYS_ADMIN for TIOCL_SELMOUSEREPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or Consolation), and they are the only legit use case: To quote console_codes(4): The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it would be difficult to find good reasons for doing that, given that it would interfere with the reports that GPM is sending. More information on the interaction between GPM, terminals and th ---truncated---
AI-Powered Analysis
Technical Analysis
CVE-2025-37814 is a vulnerability in the Linux kernel related to the handling of the TIOCL_SELMOUSEREPORT ioctl command within the tty subsystem. This ioctl is used to enable mouse reporting on virtual terminals, primarily intended for mouse daemons such as GPM (General Purpose Mouse) or Consolation, which run with CAP_SYS_ADMIN privileges. Previously, a patch (commit 2f83e38a095f) had loosened the requirement for CAP_SYS_ADMIN for some TIOCL_SETSEL modes, including TIOCL_SELMOUSEREPORT, but this was done with inconsistent logic. Specifically, the patch failed to consider that the lower four bits of the mode parameter could carry additional arguments, leading to a scenario where TIOCL_SELMOUSEREPORT could be invoked without CAP_SYS_ADMIN if no mouse button bits were set. This inconsistency introduced a security risk. The core risk arises because TIOCL_SELMOUSEREPORT allows injecting mouse reports into the terminal input stream. Attackers with access to this ioctl could simulate mouse movements and clicks, which many terminal applications (including libreadline and bash) might misinterpret as legitimate keyboard input due to their handling of X11 mouse protocol escape sequences. While this injection is less powerful than the previously known TIOCSTI ioctl (which allowed arbitrary keystroke injection), it still enables partial input simulation that could be exploited for command injection or privilege escalation on the same terminal session. The vulnerability was addressed by reverting the requirement that all uses of TIOCL_SELMOUSEREPORT require CAP_SYS_ADMIN, restoring the original security posture. This change ensures that only trusted processes (like mouse daemons running with administrative capabilities) can use this ioctl, mitigating the risk of unauthorized input injection. This vulnerability highlights the subtle security implications of ioctl permissions and the importance of strict capability checks in kernel interfaces that interact with user input streams.
Potential Impact
For European organizations, especially those running Linux servers or workstations with virtual terminals and mouse daemons, this vulnerability could allow local attackers or compromised low-privilege users to inject input events into terminal sessions. This could lead to unauthorized command execution, privilege escalation, or disruption of terminal-based workflows. Organizations relying on Linux for critical infrastructure, development environments, or terminal-based applications could face increased risk of insider threats or lateral movement within networks. While remote exploitation is unlikely without prior access, the vulnerability could be leveraged in multi-user systems, shared hosting environments, or containerized setups where terminal access is shared or exposed. The partial input injection capability may bypass some input validation or logging mechanisms, complicating detection and response. Given the widespread use of Linux across European industries, including finance, manufacturing, and public sector, the vulnerability poses a moderate risk that requires timely patching to prevent exploitation.
Mitigation Recommendations
1. Apply the official Linux kernel patch that reinstates the CAP_SYS_ADMIN requirement for TIOCL_SELMOUSEREPORT to ensure only trusted processes can invoke this ioctl. 2. Audit and restrict access to terminal devices and ensure that only necessary processes run with CAP_SYS_ADMIN capabilities. 3. Monitor and limit the use of mouse daemons like GPM or Consolation to trusted environments; disable or remove them if not required. 4. Implement strict user privilege separation and avoid granting unnecessary capabilities to untrusted users or processes. 5. Employ terminal input monitoring and anomaly detection to identify unusual mouse or keyboard input sequences that could indicate exploitation attempts. 6. Educate system administrators about the risks of ioctl misuse and encourage regular kernel updates. 7. For environments using containerization or virtualization, ensure that container privileges do not allow unauthorized ioctl access to host terminals. 8. Review and harden terminal application configurations (e.g., bash, libreadline) to handle unexpected input sequences more securely, if possible.
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-04-16T04:51:23.946Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9819c4522896dcbd881e
Added to database: 5/21/2025, 9:08:41 AM
Last enriched: 7/3/2025, 11:41:06 PM
Last updated: 8/13/2025, 7:28:54 PM
Views: 14
Related Threats
CVE-2025-47206: CWE-787 in QNAP Systems Inc. File Station 5
HighCVE-2025-5296: CWE-59 Improper Link Resolution Before File Access ('Link Following') in Schneider Electric SESU
HighCVE-2025-6625: CWE-20 Improper Input Validation in Schneider Electric Modicon M340
HighCVE-2025-57703: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in Delta Electronics DIAEnergie
MediumCVE-2025-57702: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in Delta Electronics DIAEnergie
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.