https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 21:42:00 +0000 https://vulnerability.circl.lu/vuln/cve-2024-50100 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: gadget: dummy-hcd: Fix &#34;task hung&#34; problem</p> <p>The syzbot fuzzer has been encountering &#34;task hung&#34; 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.</p> <p>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.</p> <p>Since hrtimers have no API for telling when they are queued and the callback isn&#39;t running, the driver must keep track of this for itself. That&#39;s what this patch does, adding a new &#34;timer_pending&#34; flag and setting or clearing it at the appropriate times.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: gadget: dummy-hcd: Fix &#34;task hung&#34; problem</p> <p>The syzbot fuzzer has been encountering &#34;task hung&#34; 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.</p> <p>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.</p> <p>Since hrtimers have no API for telling when they are queued and the callback isn&#39;t running, the driver must keep track of this for itself. That&#39;s what this patch does, adding a new &#34;timer_pending&#34; flag and setting or clearing it at the appropriate times.</p> https://vulnerability.circl.lu/vuln/cve-2024-50100