https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 26 Oct 2026 13:34:52 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-99050 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gpio: mpsse: fix race when arming the IRQ poll worker</p> <p>gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv-&gt;workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free.</p> <p>Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running.</p> <p>A worker armed after the disconnect walk would still be missed, so also set a new priv-&gt;dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core&#39;s raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared.</p> <p>This issue was found by an in-house static analysis tool.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gpio: mpsse: fix race when arming the IRQ poll worker</p> <p>gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv-&gt;workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free.</p> <p>Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running.</p> <p>A worker armed after the disconnect walk would still be missed, so also set a new priv-&gt;dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core&#39;s raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared.</p> <p>This issue was found by an in-house static analysis tool.</p> https://db.gcve.eu/vuln/fkie_cve-2026-99050 https://db.gcve.eu/vuln/ghsa-77g9-3gmv-7p3q <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gpio: mpsse: fix race when arming the IRQ poll worker</p> <p>gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv-&gt;workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free.</p> <p>Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running.</p> <p>A worker armed after the disconnect walk would still be missed, so also set a new priv-&gt;dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core&#39;s raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared.</p> <p>This issue was found by an in-house static analysis tool.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>gpio: mpsse: fix race when arming the IRQ poll worker</p> <p>gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv-&gt;workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free.</p> <p>Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running.</p> <p>A worker armed after the disconnect walk would still be missed, so also set a new priv-&gt;dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core&#39;s raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared.</p> <p>This issue was found by an in-house static analysis tool.</p> https://db.gcve.eu/vuln/ghsa-77g9-3gmv-7p3q https://db.gcve.eu/vuln/msrc_cve-2026-99050 msrc_CVE-2026-99050 https://db.gcve.eu/vuln/msrc_cve-2026-99050