GHSA-RF84-P87X-87H6

Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-18 18:32
VLAI
Details

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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-98859"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-18T16:17:40Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: stop the release timer from being rearmed on remove\n\nmt_remove() quiesces the sticky-finger timer before stopping the\nhardware:\n\n    timer_delete_sync(\u0026td-\u003erelease_timer);\n\n    sysfs_remove_group(\u0026hdev-\u003edev.kobj, \u0026mt_attribute_group);\n    hid_hw_stop(hdev);\n\ntimer_delete_sync() waits for a running callback and dequeues the timer,\nbut it does not stop the timer from being armed again. The transport is\nstill delivering reports at that point, and the report path rearms it:\n\n    if (app-\u003equirks \u0026 MT_QUIRK_STICKY_FINGERS) {\n        if (td-\u003emt_io_flags \u0026 MT_IO_SLOTS_MASK)\n            mod_timer(\u0026td-\u003erelease_timer,\n                      jiffies + msecs_to_jiffies(100));\n\nA report that arrives after timer_delete_sync() has returned therefore\nleaves the timer queued. td is allocated with devm_kzalloc() against\nhdev-\u003edev, so it is freed when the driver is unbound, after mt_remove()\nreturns. When the timer fires afterwards, mt_expired_timeout()\ndereferences the freed td:\n\n    struct mt_device *td = timer_container_of(td, t, release_timer);\n    struct hid_device *hdev = td-\u003ehdev;\n\n    if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, \u0026td-\u003emt_io_flags))\n\nSimply moving the teardown after hid_hw_stop() does not fix this on its\nown, because mt_expired_timeout() calls mt_release_contacts(), which\nwalks hdev-\u003einputs; the timer still has to be quiesced before\nhid_hw_stop() tears the input devices down.\n\nUse timer_shutdown_sync() instead, which additionally makes any later\nmod_timer() a no-op, so neither ordering constraint has to be traded off\nagainst the other. This is the final-teardown pattern the function was\nintroduced for, and hid-wiimote already uses it for the same reason.",
  "id": "GHSA-rf84-p87x-87h6",
  "modified": "2026-10-18T18:32:06Z",
  "published": "2026-10-18T18:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98859"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0c19a6c1d25fd5ed66d1f80dc6f6e56cc1f0a787"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1f1bd9a3117f082eb891c0986c4f0e04cd974c9a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5acb2dace582f061aab5e14c399ac9480315f44b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0125ca86e405b8a704e96157a6c10ca51087652"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.