CVE-2026-89626

What it actually does

A use-after-free in the Linux kernel HID custom-sensor driver occurs when hid_sensor_custom_add_attributes() creates per-field sysfs groups and sysfs_create_group() fails after some groups already exist. The error path returned without removing those groups, so later teardown could free sensor_inst->fields while enable_sensor still pointed into that array. Kernel memory corruption, host crash, or kernel-context code execution can follow, with high impact to confidentiality, integrity, and availability.

Why it matters to the business

An affected Linux host can be crashed or fully taken over, causing outage, data theft, or tampering. The issue is reachable from the adjacent network without credentials or user interaction, which matters anywhere untrusted HID or custom-sensor devices can attach. It is not in CISA KEV, has no reported exploit maturity, and is not tied to ransomware; urgency comes from CVSS 8.8 and the 38 days since publication rather than confirmed in-the-wild use. Until distribution kernels include the cleanup fix, custom HID sensor hosts carry elevated host-compromise and downtime risk.

How an attack unfolds

An attacker with adjacent access causes custom HID sensor field-attribute registration to fail after some sysfs groups have been created. Incomplete cleanup leaves enable_sensor able to touch pointers into a freed fields array. Subsequent use of that still-exposed path turns the use-after-free into kernel memory corruption, a denial of service, or kernel-level control of the host. No named threat actors or ransomware campaigns are associated with this CVE, and no public exploit activity is reported.

How to fix it

Apply the upstream Linux kernel change that adds an unwind path in hid_sensor_custom_add_attributes() so already-created sysfs groups are removed on failure and enable_sensor is exposed only after field attributes are fully ready. Install a distribution or vendor kernel that includes that HID sensor-custom cleanup and reboot into it. Exact package versions were not published with this record, so follow your distro kernel advisory. If a patched kernel is not yet available, unload or blacklist hid-sensor-custom where custom HID sensors are not required, and block untrusted HID/custom-sensor devices from attaching.

How to confirm the fix worked

Confirm the running kernel changelog or patch set includes the hid_sensor_custom_add_attributes unwind / field sysfs group cleanup, and that uname -r matches a build that contains it. Inventory hosts that load hid-sensor-custom or related HID sensor hub modules and verify they have rebooted onto the fixed kernel. In a controlled lab, exercise custom HID sensor registration including failed group creation and confirm groups are removed, enable_sensor is not exposed early, and no oops or KASAN use-after-free appears.

Typical attack path

1. Gain adjacent access to a Linux system that loads the HID custom sensor driver
2. Cause custom sensor field sysfs group creation to fail after some groups already exist
3. Leave enable_sensor able to reference the incompletely cleaned fields array
4. Trigger kernel use of those dangling field pointers
5. Convert the use-after-free into a host crash or kernel-level compromise

How to detect it

There is no public exploit campaign, so look for post-crash forensics rather than a known payload. Review kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent) around HID device attach for oops, BUG, KASAN use-after-free, or unable-to-handle paging errors whose call traces mention hid_sensor_custom, hid-sensor-custom, or enable_sensor. Correlate those events with unexpected custom HID sensor insertion or failed probe of custom sensor fields. Memory-debug kernels (KASAN/KFENCE) will show the UAF more clearly; production oopses may only show a paging fault in the HID sensor custom path. Absence of these logs does not prove the bug was never hit, only that it did not leave a surviving crash record.

• hid_sensor_custom_add_attributes
• hid-sensor-custom
• hid_sensor_custom
• BUG: KASAN: use-after-free
• Unable to handle kernel paging request

What your security team should do

• Prioritize kernel updates and reboots on hosts that load HID custom or sensor drivers, given CVSS 8.8 and adjacent unauthenticated reachability
• Inventory systems enumerating custom HID sensors and patch or isolate them until the cleanup fix is installed
• Restrict untrusted HID device attachment and consider blacklisting hid-sensor-custom where the feature is unused
• Watch kernel logs for hid-sensor-custom oops, KASAN use-after-free, or paging errors until fleets are patched
• Track distribution kernel advisories for the HID sensor-custom sysfs cleanup; there is no CISA KEV due date, but do not delay given high impact and lack of listed fixed package versions