https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 20:33:51 +0000 https://vulnerability.circl.lu/vuln/cve-2026-53308 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: max77705: Free allocated workqueue and fix removal order</p> <p>Use devm interface for allocating workqueue to fix two bugs at the same time:</p> <p>1. Driver leaks the memory on remove(), because the workqueue is not destroyed.</p> <p>2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt.</p> <p>The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory.</p> <p>Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any &#34;%&#34; character in device name as format.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: max77705: Free allocated workqueue and fix removal order</p> <p>Use devm interface for allocating workqueue to fix two bugs at the same time:</p> <p>1. Driver leaks the memory on remove(), because the workqueue is not destroyed.</p> <p>2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt.</p> <p>The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory.</p> <p>Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any &#34;%&#34; character in device name as format.</p> https://vulnerability.circl.lu/vuln/cve-2026-53308