CVE-2026-45969

What it actually does

This flaw is a local availability vulnerability in the Linux kernel PlayStation HID driver. The driver calls input_ff_create_memless() while creating a PlayStation gamepad input device but does not verify whether that call failed. If force-feedback support is not initialized correctly and force-feedback effects are later triggered, the kernel may dereference or use invalid driver state, causing incorrect behavior, a kernel warning/oops, or a system crash. The CVSS vector indicates local access is required, exploitation is low complexity, no user interaction is required, and the primary impact is high availability loss rather than confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt services running on them, especially where local users, containers with device access, kiosks, gaming/workstation systems, lab systems, or physical USB/Bluetooth peripheral access are in scope. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known mature public exploit, so it is generally lower urgency than remotely exploitable kernel bugs; however, it should still be addressed through normal kernel update cycles because kernel crashes can cause downtime, data loss from abrupt reboots, and operational disruption.

How an attack unfolds

An attacker first needs local capability to interact with the affected kernel driver, typically by attaching or emulating a PlayStation-compatible HID controller over USB or Bluetooth, or by otherwise reaching the relevant input device path from a local session. The vulnerable code path occurs during creation of the gamepad input device, where the driver attempts to initialize memless force-feedback support but fails to validate the return value. If initialization fails and the system later processes force-feedback effects for that device, the driver can operate on improperly initialized state. The attacker then triggers force-feedback activity, for example through local input APIs or an application that sends rumble/force-feedback effects, causing the kernel to misbehave and potentially crash. There is no indication from the provided data that this vulnerability enables privilege escalation or remote code execution.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the hid-playstation fix adding return-value validation for input_ff_create_memless(). Because no exact fixed versions were provided, use the relevant distribution, appliance, or kernel vendor advisory to identify the corrected kernel package for each supported branch. Where immediate patching is not possible, reduce exposure by disabling or avoiding the hid-playstation module where operationally feasible, restricting local users from accessing input/event devices, limiting USB/Bluetooth peripheral attachment, disabling untrusted HID device use on shared systems, and applying physical access controls. For high-availability systems, schedule kernel upgrades with reboot planning and test peripheral compatibility before broad rollout.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected kernel build and include or load the hid-playstation driver. Validate remediation by verifying the installed kernel version matches a vendor build containing the fix, rebooting into the updated kernel, and confirming the vulnerable module is updated or no longer present. Review distribution changelogs or kernel source/package metadata for the HID PlayStation fix referencing input_ff_create_memless() return-value handling. Functional validation can include connecting a PlayStation-compatible controller and exercising force-feedback features while monitoring dmesg/journal logs for kernel warnings, oopses, panics, or hid-playstation errors. If mitigation rather than patching is used, confirm that the hid-playstation module cannot be loaded or that untrusted users cannot access relevant /dev/input/event* devices.

Typical attack path

1. Obtain local access to an affected Linux system or physical/proximate access sufficient to attach or emulate a PlayStation HID controller.
2. Cause the affected hid-playstation driver path to create a gamepad input device.
3. Induce or rely on failure of input_ff_create_memless() during device initialization.
4. Trigger force-feedback effects against the affected input device through local input APIs or an application using rumble functionality.
5. Cause a kernel fault, oops, panic, service interruption, or system reboot, resulting in denial of service.

How to detect it

To determine whether this was already exploited, review host-level kernel logs rather than application logs. Relevant sources include dmesg output, systemd journal entries for the kernel facility, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, and endpoint telemetry showing USB/Bluetooth device attachment. Look for kernel oops, panic, BUG, WARNING, NULL pointer dereference, general protection fault, or hung-task events near hid-playstation, PlayStation controller connection, input device creation, or force-feedback activity. Correlate suspicious crashes with local user sessions, recent connection of Sony/PlayStation-compatible HID devices, Bluetooth pairing events, access to /dev/input/event* nodes, and applications that may issue rumble or force-feedback commands. Because no public exploit indicators or threat actors are identified, detection should focus on behavioral artifacts: repeated controller attach/detach events followed by kernel faults, crash stacks mentioning hid-playstation or input_ff_create_memless, and unexplained reboots following force-feedback use.

• hid-playstation
• input_ff_create_memless
• ps_gamepad_create
• force feedback
• Force feedback
• ff-memless
• kernel NULL pointer dereference
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• WARNING: CPU:
• Call Trace:
• /dev/input/event
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• Sony Interactive Entertainment Wireless Controller
• PlayStation Controller
• DualShock
• DualSense

What your security team should do

• Inventory Linux systems where local users, untrusted workloads, kiosks, workstations, or physical peripheral access could reach HID/input devices.
• Prioritize kernel updates for shared-user systems, desktops/workstations, lab machines, gaming/VR systems, and any production Linux hosts that allow USB/Bluetooth peripheral attachment.
• Track vendor kernel advisories and deploy the first supported kernel package that includes the hid-playstation input_ff_create_memless() return-value check.
• Where patching is delayed, restrict access to /dev/input/event* devices and prevent untrusted USB/Bluetooth HID peripherals from being attached or paired.
• Consider blacklisting or disabling the hid-playstation module on systems that do not require PlayStation controller support.
• Monitor for kernel oops, panic, and hid-playstation/input force-feedback errors, especially shortly after controller connection or rumble/force-feedback activity.
• Treat any unexplained local kernel crash involving hid-playstation or input_ff_create_memless as a potential denial-of-service attempt and preserve kernel logs for forensic review.