CVE-2026-46232

What it actually does

This is an out-of-bounds read in the Linux kernel PlayStation HID driver. A malicious or malformed DualShock 4-compatible device can claim an excessive number of touch reports, causing dualshock4_parse_report to read past the end of the touch_reports array. Up to roughly 2 KiB of adjacent kernel memory may be read and, depending on report contents, exposed through evdev input events. The bug can disclose kernel memory and may also destabilize the kernel or affected input subsystem.

Why it matters to the business

Systems that allow untrusted USB or Bluetooth HID devices can be exposed to local-adjacent attacks that may leak sensitive kernel memory or cause instability. This is most relevant to workstations, kiosks, gaming/interactive systems, test labs, and any Linux endpoint where users or attackers can connect or pair peripherals. The CVSS score is high, but EPSS is currently low and there is no known KEV listing or public exploit maturity reported, so prioritization should focus first on systems where physical or Bluetooth peripheral access is realistic.

How an attack unfolds

An attacker needs the ability to present a malicious PlayStation-compatible HID device to the target, typically by USB connection or Bluetooth pairing. The device sends a crafted DualShock 4 input report with a num_touch_reports value larger than the kernel driver's fixed touch_reports array. A vulnerable kernel loops over the attacker-supplied count without clamping it, reading beyond the valid report buffer. If the parsed data meets the driver's conditions for touch event emission, portions of adjacent memory can be surfaced to user space through evdev events. In some cases, malformed parsing may also contribute to kernel warnings, driver malfunction, or system instability. There is no indication from the provided data that this is remotely exploitable over the network without first introducing a malicious or spoofed HID device.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the hid-playstation fix which clamps num_touch_reports to the maximum touch_reports array size. No exact fixed versions were provided, so use vendor advisories, distribution security trackers, and kernel changelogs to identify the patched kernel for each platform. Where immediate patching is not possible, reduce exposure by preventing untrusted USB and Bluetooth HID devices, disabling Bluetooth pairing where unnecessary, enforcing USB device control policies, and blacklisting or unloading the hid-playstation module if PlayStation controller support is not required. Example mitigations include module blacklisting through modprobe configuration, restricting access to /dev/input/event* devices, and applying endpoint/physical security controls for systems accessible to users or the public.

How to confirm the fix worked

Confirm the running kernel package includes the patch to drivers/hid/hid-playstation.c that clamps the device-supplied num_touch_reports value before iterating over touch_reports. Validate using vendor package metadata, kernel changelog entries, or source inspection. Confirm the running kernel after reboot with uname -a and package-manager queries. If PlayStation controller support is not required, verify the hid-playstation module is not loaded and cannot autoload. For exposure validation, check whether systems allow USB or Bluetooth HID pairing and whether PlayStation/DualShock 4 devices are enumerated. In controlled testing only, a malformed HID report should no longer cause out-of-bounds parsing, leaked evdev events, kernel warnings, or crashes.

Typical attack path

1. Attacker obtains physical proximity, USB access, or Bluetooth pairing opportunity to a Linux system.
2. Attacker connects or pairs a malicious device that identifies as a DualShock 4 or compatible PlayStation HID controller.
3. The malicious device sends a crafted touchpad report with an excessive num_touch_reports value.
4. The vulnerable hid-playstation driver processes the report and reads beyond the touch_reports array.
5. Kernel-adjacent memory may be emitted through evdev input events if parsed flags cause event generation.
6. Attacker-controlled or attacker-accessible user-space code reads the corresponding /dev/input/event* stream to collect leaked data, or the malformed report causes system instability.

How to detect it

There is no reliable, unique on-host indicator that proves exploitation because the attack is delivered through crafted HID input reports and may only appear as normal input-device activity. Investigate systems with unexpected USB or Bluetooth PlayStation/DualShock controller enumeration, especially where such devices are not expected. Review kernel logs, systemd journal, udev logs, Bluetooth pairing logs, endpoint device-control telemetry, and audit logs for new HID devices, hid-playstation driver activity, /dev/input/event* access, and kernel warnings or crashes near the time of device connection. Useful sources include journalctl -k, /var/log/kern.log, /var/log/syslog, auditd records for /dev/input/event* reads, udev events, bluetoothd logs, and EDR USB/Bluetooth device inventory. Look for suspicious local processes opening evdev devices immediately after a controller is connected, because leaked data would be consumed from input event streams rather than written to a distinctive file. Absence of these artifacts does not rule out exploitation.

What your security team should do

• Prioritize patching Linux endpoints where untrusted users can connect USB devices or pair Bluetooth peripherals, including kiosks, shared workstations, labs, and public-access systems.
• Deploy the vendor-patched kernel containing the hid-playstation num_touch_reports clamp and ensure systems are rebooted into the fixed kernel.
• If patching is delayed, disable or blacklist the hid-playstation driver where PlayStation controller support is not business-required.
• Restrict USB and Bluetooth HID device introduction using endpoint controls, device allowlisting, BIOS/UEFI policy, MDM, or physical port controls.
• Review logs and asset data for unexpected PlayStation/DualShock controller connections, especially on servers or non-interactive systems.
• Limit permissions to /dev/input/event* devices so only trusted local users and services can read raw input events.
• Monitor for kernel oops, HID driver warnings, or unexpected input-device enumeration around the time of suspicious peripheral activity.