CVE-2026-43152

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel HID subsystem, specifically in the hid-pl driver handling force-feedback initialization. If initialization fails but the error is not correctly propagated, the driver can later dereference a NULL pointer when force feedback is used. A local user with access to the affected HID device path can trigger a kernel fault, which may crash the system or make it unavailable. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems to crash or become unavailable, interrupting workloads, user sessions, kiosks, embedded systems, workstations, or servers that expose vulnerable HID devices. The practical risk is lower than remotely exploitable vulnerabilities because an attacker needs local access and a relevant device/driver path, EPSS is very low, it is not listed in CISA KEV, and there is no known public exploit maturity reported. However, systems that rely on continuous availability or that allow untrusted local users, peripherals, containers with device passthrough, or physical device access should treat this as a stability and uptime risk.

How an attack unfolds

An attacker first obtains local execution on a Linux system where the affected hid-pl driver is present and a compatible HID force-feedback device or emulated device is accessible. The attacker triggers a driver probe or initialization path that fails in a way the vulnerable kernel does not correctly report. Later, the attacker invokes force-feedback functionality through the exposed input or HID interface. Because the driver continues after a failed initialization state, the force-feedback operation reaches a NULL pointer and causes a kernel oops or panic, resulting in denial of service. There is no indication from the provided intelligence that this vulnerability is being exploited in the wild, used by ransomware, or associated with named threat actors.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream fix for hid-pl probe error handling. Because no exact fixed versions were provided, use the latest security kernel packages from the operating system or appliance vendor and verify the vendor advisory for this CVE. Where immediate patching is not possible, reduce exposure by restricting local user access, limiting device passthrough to virtual machines and containers, blocking untrusted USB/HID peripherals, disabling or blacklisting the affected hid-pl driver if not required, and enforcing physical access controls on systems where local device interaction is possible. Any mitigation that removes access to the vulnerable HID driver path or prevents untrusted users from exercising force-feedback functionality reduces risk but should be tested for hardware compatibility impact.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor-fixed build containing the hid-pl probe error handling patch, not merely that the package is installed. Reboot into the patched kernel where required. Check loaded modules and kernel configuration to determine whether the affected HID driver is present or in use. Validate that no vulnerable kernel remains selectable in bootloader entries. For mitigation validation, confirm that the hid-pl driver is not loaded where it is not needed, untrusted users cannot access relevant /dev/input or HID device nodes, and USB/HID passthrough policies prevent exposure to untrusted contexts. Review vendor advisories or kernel changelogs for references to HID hid-pl probe error handling, NULL pointer handling, or force-feedback initialization fixes.

Typical attack path

1. Gain local access to an affected Linux host or an execution context with access to relevant HID/input device interfaces.
2. Identify that the hid-pl driver is loaded or can be triggered by a compatible HID device.
3. Cause or rely on a probe/init failure condition in the hid-pl force-feedback initialization path.
4. Invoke force-feedback functionality through the HID/input interface.
5. Trigger a NULL pointer dereference in kernel context.
6. Cause a kernel oops, panic, reboot, or system instability, producing denial of service.

How to detect it

To determine whether exploitation or attempted triggering has already occurred, review kernel and system logs for crashes associated with the HID subsystem, hid-pl, force-feedback initialization, NULL pointer dereferences, kernel oops events, panics, spontaneous reboots, or watchdog resets. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dump directories, kdump/vmcore artifacts, and endpoint telemetry showing recent access to /dev/input or /dev/hidraw devices. Correlate crash timestamps with local user sessions, USB device attach events, udev events, container or VM passthrough activity, and execution of programs that interact with force-feedback HID devices. There are no known network indicators because the vulnerability is local. Absence of logs does not prove non-exploitation if kernel logs are volatile, overwritten, or the system hard-rebooted without persistent crash capture.

• hid-pl
• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• hid
• force feedback
• ff_init
• plff
• /dev/input
• /dev/hidraw
• /var/crash
• /var/lib/systemd/coredump
• vmcore
• kdump

What your security team should do

• Prioritize patching on Linux systems that allow local shell access by multiple users, physical peripheral access, kiosk use, lab use, VDI use, or VM/container device passthrough.
• Update to the latest vendor-supported kernel containing the fix and reboot systems so the patched kernel is actively running.
• Inventory systems where HID force-feedback devices, gaming controllers, specialized USB peripherals, or hid-pl driver support are enabled.
• Where the driver is unnecessary, consider disabling or blacklisting hid-pl after compatibility testing.
• Restrict access to /dev/input, /dev/hidraw*, and USB/HID passthrough to trusted users and workloads only.
• Monitor kernel logs for NULL pointer dereferences, kernel oops, panic events, and hid-pl or force-feedback related crashes.
• Because EPSS is very low and there is no KEV listing or known exploit maturity, handle this through normal kernel patch cycles unless the environment has high local-user or physical-access exposure.