https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 07:37:32 +0000 https://vulnerability.circl.lu/vuln/cve-2026-43061 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>serial: 8250: Fix TX deadlock when using DMA</p> <p>`dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma-&gt;tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma-&gt;tx_running` will never get cleared and we will never schedule new TX DMA transactions again.</p> <p>This change makes it so we clear `dma-&gt;tx_running` after we terminate the DMA transaction. This is &#34;safe&#34; because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma-&gt;tx_running` is serialized.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>serial: 8250: Fix TX deadlock when using DMA</p> <p>`dmaengine_terminate_async` does not guarantee that the `__dma_tx_complete` callback will run. The callback is currently the only place where `dma-&gt;tx_running` gets cleared. If the transaction is canceled and the callback never runs, then `dma-&gt;tx_running` will never get cleared and we will never schedule new TX DMA transactions again.</p> <p>This change makes it so we clear `dma-&gt;tx_running` after we terminate the DMA transaction. This is &#34;safe&#34; because `serial8250_tx_dma_flush` is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to `dma-&gt;tx_running` is serialized.</p> https://vulnerability.circl.lu/vuln/cve-2026-43061