Description
In the Linux kernel, the following vulnerability has been resolved:

HID: universal-pidff: stop the device when force-feedback init fails

universal_pidff_probe() starts the device with hid_hw_start() and then, if
force-feedback initialisation fails, returns the error through a label that
only does "return error". The device is left started.

The HID core does not unwind on the driver's behalf. __hid_device_probe()
releases the devres group, closes the report and clears hdev->driver:

if (ret) {
devres_release_group(&hdev->dev, hdev->devres_group_id);
hid_close_report(hdev);
hdev->driver = NULL;
}

The hidraw character device that hid_hw_start() registered through
hid_connect() is allocated with kzalloc() and added with cdev_device_add(),
so it is not devres-managed and survives that. With hdev->driver NULL,
hid_device_remove() skips hid_hw_stop() as well, because it only unwinds
while a driver is still attached. The registration therefore outlives the
device on both paths.

Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports
a use-after-free write from hidraw_open() -> hid_hw_open() -> the
transport's open callback, which takes a spinlock inside the freed object.
A descriptor that carries a PID usage page and no input reports is enough:
hidraw claims the device so hid_hw_start() succeeds, while hid->inputs
stays empty so force-feedback init fails. The other failure returns in
hid_pidff_init_with_quirks() - no output reports, an allocation failure,
pidff_init_fields(), pidff_check_autocenter(), an unusable effect count,
input_ff_create() - all reach the same label.

Stop the device on that path. hid-dr.c and hid-emsff.c, which start the
device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do
this. The two earlier gotos must keep returning without hid_hw_stop(),
since neither has a started device, so give the path that fails after the
start its own label.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Published: 2026-09-11
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory corruption via /dev/hidraw use‑after‑free
Action: Apply Patch
AI Analysis

Impact

The Linux kernel HID universal‑pidff driver starts a device with hid_hw_start and, when force‑feedback initialization fails, it leaves the device started while clearing the driver pointer. The /dev/hidraw character device created by hid_connect persists, causing the device to be reachable after the driver has been detached. Opening the file triggers a write into freed memory, resulting in a use‑after‑free that can corrupt kernel memory and may allow an attacker with local access to execute arbitrary code or elevate privileges.

Affected Systems

Any Linux system whose kernel contains the universal‑pidff driver before the fix is applied is affected. Distributions shipping those kernel versions are vulnerable when a no input reports. No other vendors or products are reported to be affected.

Risk and Exploitability

The CVSS score of 6.3 signals a moderate severity. The EPSS score of < 1 exploration, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires local access to a matching HID device and the ability to open its /dev/hidraw entry; an attacker would trigger the faulty force‑feedback initialization path to cause the use‑after‑free.

Generated by OpenCVE AI on September 13, 2026 at 05:30 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the patch for the universal‑pidff driver 01d9874e84d3ab78fd212ad822412eb3af84497f.
  • As a temporary workaround, disable or unload the universal‑pidff driver for the affected device, for removing the device from the system.
  • Restrict access to /dev/hidraw* devices by setting strict file permissions so that only privileged users can open them until a permanent fix is in place.

Generated by OpenCVE AI on September 13, 2026 at 05:30 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 13 Sep 2026 06:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 6.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 12 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 6.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H'}

threat_severity

Moderate


Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: HID: universal-pidff: stop the device when force-feedback init fails universal_pidff_probe() starts the device with hid_hw_start() and then, if force-feedback initialisation fails, returns the error through a label that only does "return error". The device is left started. The HID core does not unwind on the driver's behalf. __hid_device_probe() releases the devres group, closes the report and clears hdev->driver: if (ret) { devres_release_group(&hdev->dev, hdev->devres_group_id); hid_close_report(hdev); hdev->driver = NULL; } The hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added with cdev_device_add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid_device_remove() skips hid_hw_stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths. Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid_pidff_init_with_quirks() - no output reports, an allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, input_ff_create() - all reach the same label. Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do this. The two earlier gotos must keep returning without hid_hw_stop(), since neither has a started device, so give the path that fails after the start its own label. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Title HID: universal-pidff: stop the device when force-feedback init fails
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-13T06:32:04.742Z

Reserved: 2026-09-11T19:38:34.737Z

Link: CVE-2026-89624

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:19:47.750

Modified: 2026-09-13T07:17:27.800

Link: CVE-2026-89624

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:45:21Z

Links: CVE-2026-89624 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-13T05:45:18Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference