CVE-2025-37814

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT<br /> <br /> This requirement was overeagerly loosened in commit 2f83e38a095f<br /> ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as<br /> it turns out,<br /> <br /> (1) the logic I implemented there was inconsistent (apologies!),<br /> <br /> (2) TIOCL_SELMOUSEREPORT might actually be a small security risk<br /> after all, and<br /> <br /> (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse<br /> daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN<br /> already.<br /> <br /> In more detail:<br /> <br /> 1. The previous patch has inconsistent logic:<br /> <br /> In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes<br /> without CAP_SYS_ADMIN"), we checked for sel_mode ==<br /> TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of<br /> this "mode" parameter were actually used as an additional way to<br /> pass an argument. So the patch did actually still require<br /> CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not<br /> require it if none of the mouse buttons bits are set.<br /> <br /> This logic is inconsistent and was not intentional. We should have<br /> the same policies for using TIOCL_SELMOUSEREPORT independent of the<br /> value of the "hidden" mouse button argument.<br /> <br /> I sent a separate documentation patch to the man page list with<br /> more details on TIOCL_SELMOUSEREPORT:<br /> https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/<br /> <br /> 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can<br /> let an attacker simulate "keyboard" input to command line<br /> applications on the same terminal, like TIOCSTI and some other<br /> TIOCLINUX "selection mode" IOCTLs.<br /> <br /> By enabling mouse reporting on a terminal and then injecting mouse<br /> reports through TIOCL_SELMOUSEREPORT, an attacker can simulate<br /> mouse movements on the same terminal, similar to the TIOCSTI<br /> keystroke injection attacks that were previously possible with<br /> TIOCSTI and other TIOCL_SETSEL selection modes.<br /> <br /> Many programs (including libreadline/bash) are then prone to<br /> misinterpret these mouse reports as normal keyboard input because<br /> they do not expect input in the X11 mouse protocol form. The<br /> attacker does not have complete control over the escape sequence,<br /> but they can at least control the values of two consecutive bytes<br /> in the binary mouse reporting escape sequence.<br /> <br /> I went into more detail on that in the discussion at<br /> https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/<br /> <br /> It is not equally trivial to simulate arbitrary keystrokes as it<br /> was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be<br /> disabled")), but the general mechanism is there, and together with<br /> the small number of existing legit use cases (see below), it would<br /> be better to revert back to requiring CAP_SYS_ADMIN for<br /> TIOCL_SELMOUSEREPORT, as it was already the case before<br /> commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without<br /> CAP_SYS_ADMIN").<br /> <br /> 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or<br /> Consolation), and they are the only legit use case:<br /> <br /> To quote console_codes(4):<br /> <br /> The mouse tracking facility is intended to return<br /> xterm(1)-compatible mouse status reports. Because the console<br /> driver has no way to know the device or type of the mouse, these<br /> reports are returned in the console input stream only when the<br /> virtual terminal driver receives a mouse update ioctl. These<br /> ioctls must be generated by a mouse-aware user-mode application<br /> such as the gpm(8) daemon.<br /> <br /> Jared Finder has also confirmed in<br /> https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/<br /> that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it<br /> would be difficult to find good reasons for doing that, given that<br /> it would interfere with the reports that GPM is sending.<br /> <br /> More information on the interaction between GPM, terminals and th<br /> ---truncated---