Skip to content
Fencer Vulns
high 7.8

CVE-2025-37814 json

tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT

published 2025-05-08 18 mo ago modified 2026-08-05 3 mo ago also EUVD-2025-13976

cvss
7.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 13%
public exploits
0
none known

Summary

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

Patch / fix

  • Linux Linux 6.12.26, 6.14, 6.14.5, 6.15
  • linux Debian 14, Debian 13 6.12.27-1

debian advisories DEBIAN-CVE-2025-37814

  • linux-gcp-6.14 Ubuntu 24.04 LTS 6.14.0-1011.11~24.04.1
  • linux-realtime-6.14 Ubuntu Pro Realtime 24.04 LTS 6.14.0-1010.10~24.04.1

ubuntu advisories UBUNTU-CVE-2025-37814

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-rt Real Time Module 15 SP7 6.4.0-150700.7.8.1
  • kernel-syms-rt Real Time Module 15 SP7 6.4.0-150700.7.8.1
  • kernel-source-rt Real Time Module 15 SP7 6.4.0-150700.7.8.1
  • kernel-64kb SLE Module for Basesystem 15 SP7 6.4.0-150700.53.6.1
  • kernel-syms SLE Module for Development Tools 15 SP7 6.4.0-150700.53.6.1
  • kernel-source SLE Module for Development Tools 15 SP7, SLE Module for Basesystem 15 SP7 6.4.0-150700.53.6.1
  • kernel-default SLE Workstation Extension 15 SP7, SLE Module for Legacy 15 SP7, SLE Module for Basesystem 15 SP7 +2 more 6.4.0-150700.53.6.1
  • kernel-zfcpdump SLE Module for Basesystem 15 SP7 6.4.0-150700.53.6.1

suse advisories SUSE-SU-2025:02333-1SUSE-SU-2025:02307-1SUSE-SU-2025:02254-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-37814 updated cvss 5.5

kernel: tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT

  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.22% chance of exploitation in the next 30 days, higher than 13% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.