GHSA-66Q2-FFPQ-62MP

Vulnerability from github – Published: 2024-11-05 18:32 – Updated: 2024-11-12 15:30
VLAI?
Details

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

USB: gadget: dummy-hcd: Fix "task hung" problem

The syzbot fuzzer has been encountering "task hung" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs.

The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued or its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there.

Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new "timer_pending" flag and setting or clearing it at the appropriate times.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50100"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T18:15:13Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: dummy-hcd: Fix \"task hung\" problem\n\nThe syzbot fuzzer has been encountering \"task hung\" problems ever\nsince the dummy-hcd driver was changed to use hrtimers instead of\nregular timers.  It turns out that the problems are caused by a subtle\ndifference between the timer_pending() and hrtimer_active() APIs.\n\nThe changeover blindly replaced the first by the second.  However,\ntimer_pending() returns True when the timer is queued but not when its\ncallback is running, whereas hrtimer_active() returns True when the\nhrtimer is queued _or_ its callback is running.  This difference\noccasionally caused dummy_urb_enqueue() to think that the callback\nroutine had not yet started when in fact it was almost finished.  As a\nresult the hrtimer was not restarted, which made it impossible for the\ndriver to dequeue later the URB that was just enqueued.  This caused\nusb_kill_urb() to hang, and things got worse from there.\n\nSince hrtimers have no API for telling when they are queued and the\ncallback isn\u0027t running, the driver must keep track of this for itself.\nThat\u0027s what this patch does, adding a new \"timer_pending\" flag and\nsetting or clearing it at the appropriate times.",
  "id": "GHSA-66q2-ffpq-62mp",
  "modified": "2024-11-12T15:30:32Z",
  "published": "2024-11-05T18:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50100"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5189df7b8088268012882c220d6aca4e64981348"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7d85884576a3be3616c260fc1fa862a59579d1ab"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cf7ee2291da551fc4b109fda1f6a332cb8212065"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f828205ee3e4ddc712a13fba6c9902d51e91ddaf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…