Cloudanix VulnDB

CVE-2026-98859

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing error in the Linux kernel's handling of touch input devices can cause the system to crash or allow an attacker with physical access to run code after the device is unplugged.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel HID multitouch driver: mt_remove() calls timer_delete_sync() but reports can still arrive and rearm the release_timer via mod_timer(); later mt_expired_timeout() dereferences the already-freed td structure allocated with devm_kzalloc.

Why it matters to the business

Kernel panic or local privilege escalation on Linux systems handling multitouch HID devices; low immediate risk given 0.00157 EPSS, flat trend, and no KEV listing five days after 2026-10-18 disclosure.

How an attack unfolds

An attacker with the ability to attach or simulate a multitouch HID device triggers driver unbind while input reports continue; the race leaves the timer armed, causing mt_expired_timeout() to access freed memory after td is released.

How to fix it

Upgrade the Linux kernel to a version containing the timer_shutdown_sync() change in hid-multitouch.c; rebuild and reboot affected systems; no per-package fixed versions supplied in the advisory.

How to confirm the fix worked

Confirm the presence of timer_shutdown_sync(&td->release_timer) in mt_remove() and absence of mod_timer paths after shutdown; verify via kernel build logs or source inspection that the final-teardown pattern matches hid-wiimote.

Typical attack path

  1. Attach or emulate a multitouch HID device that sets MT_QUIRK_STICKY_FINGERS
  2. Trigger device removal or driver unbind (rmmod, unplug, or userspace action)
  3. Continue delivering input reports during the narrow window after timer_delete_sync() returns
  4. Wait for the rearmed timer to fire and execute mt_expired_timeout() on freed memory

How to detect it

Search kernel logs and crash dumps for mt_expired_timeout, release_timer, or MT_IO_FLAGS_RUNNING references; look for use-after-free warnings or oops traces on HID device removal paths; no public exploitation artifacts reported.

What your security team should do

  • Apply the upstream timer_shutdown_sync patch within normal patch windows given low EPSS and no KEV status
  • Monitor for kernel oops involving mt_expired_timeout or timer_container_of in multitouch paths
  • Restrict unprivileged USB/HID device attachment where feasible until kernels are updated

The record

In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: stop the release timer from being rearmed on remove mt_remove() quiesces the sticky-finger timer before stopping the hardware: timer_delete_sync(&td->release_timer); sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group); hid_hw_stop(hdev); timer_delete_sync() waits for a running callback and dequeues the timer, but it does not stop the timer from being armed again. The transport is still delivering reports at that point, and the report path rearms it: if (app->quirks & MT_QUIRK_STICKY_FINGERS) { if (td->mt_io_flags & MT_IO_SLOTS_MASK) mod_timer(&td->release_timer, jiffies + msecs_to_jiffies(100)); A report that arrives after timer_delete_sync() has returned therefore leaves the timer queued. td is allocated with devm_kzalloc() against hdev->dev, so it is freed when the driver is unbound, after mt_remove() returns. When the timer fires afterwards, mt_expired_timeout() dereferences the freed td: struct mt_device *td = timer_container_of(td, t, release_timer); struct hid_device *hdev = td->hdev; if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags)) Simply moving the teardown after hid_hw_stop() does not fix this on its own, because mt_expired_timeout() calls mt_release_contacts(), which walks hdev->inputs; the timer still has to be quiesced before hid_hw_stop() tears the input devices down. Use timer_shutdown_sync() instead, which additionally makes any later mod_timer() a no-op, so neither ordering constraint has to be traded off against the other. This is the final-teardown pattern the function was introduced for, and hid-wiimote already uses it for the same reason.

Affected packages

Ecosystem Package Introduced Fixed