{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2025-37814 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-37814 is a high-severity vulnerability in Linux kernel, published on 8 May 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2025-37814 and fix it if it is affected.\n\nWhat it is: CVE-2025-37814 is a high-severity vulnerability in Linux kernel, published on 8 May 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2025-37814 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2025-37814/ (Markdown: https://insights.sbomify.com/CVE-2025-37814/index.md)","id":"CVE-2025-37814","markdown":"https://insights.sbomify.com/CVE-2025-37814/index.md","name":"CVE-2025-37814","record":{"aliases":["BELL-CVE-2025-37814","DEBIAN-CVE-2025-37814","GHSA-vjw7-4w34-rrq4","UBUNTU-CVE-2025-37814"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["privilege_escalation","code_execution"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"Attackers can simulate mouse input to inject commands into terminal applications, potentially escalating privileges or executing code.","user_interaction":"not_required","vuln_class":"privilege_escalation"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\ntty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT\n\nThis requirement was overeagerly loosened in commit 2f83e38a095f\n(\"tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN\"), but as\nit turns out,\n\n  (1) the logic I implemented there was inconsistent (apologies!),\n\n  (2) TIOCL_SELMOUSEREPORT might actually be a small security risk\n      after all, and\n\n  (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse\n      daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN\n      already.\n\nIn more detail:\n\n1. The previous patch has inconsistent logic:\n\n   In commit 2f83e38a095f (\"tty: Permit some TIOCL_SETSEL modes\n   without CAP_SYS_ADMIN\"), we checked for sel_mode ==\n   TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of\n   this \"mode\" parameter were actually used as an additional way to\n   pass an argument.  So the patch did actually still require\n   CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not\n   require it if none of the mouse buttons bits are set.\n\n   This logic is inconsistent and was not intentional.  We should have\n   the same policies for using TIOCL_SELMOUSEREPORT independent of the\n   value of the \"hidden\" mouse button argument.\n\n   I sent a separate documentation patch to the man page list with\n   more details on TIOCL_SELMOUSEREPORT:\n   https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/\n\n2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can\n   let an attacker simulate \"keyboard\" input to command line\n   applications on the same terminal, like TIOCSTI and some other\n   TIOCLINUX \"selection mode\" IOCTLs.\n\n   By enabling mouse reporting on a terminal and then injecting mouse\n   reports through TIOCL_SELMOUSEREPORT, an attacker can simulate\n   mouse movements on the same terminal, similar to the TIOCSTI\n   keystroke injection attacks that were previously possible with\n   TIOCSTI and other TIOCL_SETSEL selection modes.\n\n   Many programs (including libreadline/bash) are then prone to\n   misinterpret these mouse reports as normal keyboard input because\n   they do not expect input in the X11 mouse protocol form.  The\n   attacker does not have complete control over the escape sequence,\n   but they can at least control the values of two consecutive bytes\n   in the binary mouse reporting escape sequence.\n\n   I went into more detail on that in the discussion at\n   https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/\n\n   It is not equally trivial to simulate arbitrary keystrokes as it\n   was with TIOCSTI (commit 83efeeeb3d04 (\"tty: Allow TIOCSTI to be\n   disabled\")), but the general mechanism is there, and together with\n   the small number of existing legit use cases (see below), it would\n   be better to revert back to requiring CAP_SYS_ADMIN for\n   TIOCL_SELMOUSEREPORT, as it was already the case before\n   commit 2f83e38a095f (\"tty: Permit some TIOCL_SETSEL modes without\n   CAP_SYS_ADMIN\").\n\n3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or\n   Consolation), and they are the only legit use case:\n\n   To quote console_codes(4):\n\n     The mouse tracking facility is intended to return\n     xterm(1)-compatible mouse status reports.  Because the console\n     driver has no way to know the device or type of the mouse, these\n     reports are returned in the console input stream only when the\n     virtual terminal driver receives a mouse update ioctl.  These\n     ioctls must be generated by a mouse-aware user-mode application\n     such as the gpm(8) daemon.\n\n   Jared Finder has also confirmed in\n   https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/\n   that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it\n   would be difficult to find good reasons for doing that, given that\n   it would interfere with the reports that GPM is sending.\n\n   More information on the interaction between GPM, terminals and th\n---truncated---","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT","id":"CVE-2025-37814","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"privilege_escalation","year":"2025"},"n_packages":0,"n_references":3,"next":{"headline":"misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration","id":"CVE-2025-37815"},"packages":[],"prev":{"headline":"usb: xhci: Fix invalid pointer dereference in Etron workaround","id":"CVE-2025-37813"},"products":["Linux"],"published":"2025-05-08","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"Attackers can simulate mouse input to inject commands into terminal applications, potentially escalating privileges or executing code.","url":"https://insights.sbomify.com/CVE-2025-37814/"}