// For flags

CVE-2024-50100

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

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

-
*SSVC
Descriptions

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: dummy-hcd: soluciona el problema de "tarea colgada" El fuzzer syzbot ha estado encontrando problemas de "tarea colgada" desde que se cambió el controlador dummy-hcd para usar temporizadores hrtimer en lugar de temporizadores normales. Resulta que los problemas son causados por una diferencia sutil entre las API timer_pending() y hrtimer_active(). El cambio reemplazó ciegamente la primera por la segunda. Sin embargo, timer_pending() devuelve True cuando el temporizador está en cola pero no cuando su devolución de llamada se está ejecutando, mientras que hrtimer_active() devuelve True cuando el hrtimer está en cola _o_ su devolución de llamada se está ejecutando. Esta diferencia ocasionalmente hizo que dummy_urb_enqueue() pensara que la rutina de devolución de llamada aún no había comenzado cuando, de hecho, estaba casi terminada. Como resultado, el hrtimer no se reinició, lo que hizo imposible que el controlador quitara de la cola más tarde el URB que acababa de ponerse en cola. Esto provocó que usb_kill_urb() se bloqueara y las cosas empeoraron a partir de ahí. Dado que los temporizadores hr no tienen una API para saber cuándo están en cola y la devolución de llamada no se está ejecutando, el controlador debe realizar un seguimiento de esto por sí mismo. Eso es lo que hace este parche, agregando un nuevo indicador "timer_pending" y configurándolo o borrándolo en los momentos apropiados.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:-
Exploitation
-
Automatable
-
Tech. Impact
-
* Organization's Worst-case Scenario
Timeline
  • 2024-10-21 CVE Reserved
  • 2024-11-05 CVE Published
  • 2024-11-05 CVE Updated
  • 2024-11-06 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.10 < 6.11.5
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.10 < 6.11.5"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.10 < 6.12-rc4
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.10 < 6.12-rc4"
en
Affected