https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 12:37:08 +0000 https://vulnerability.circl.lu/vuln/cve-2026-46041 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()</p> <p>hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -&gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger &#34;BUG: scheduling while atomic&#34;.</p> <p>Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow:</p> <p>1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically.</p> <p>This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all.</p> <p>This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()</p> <p>hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -&gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger &#34;BUG: scheduling while atomic&#34;.</p> <p>Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow:</p> <p>1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically.</p> <p>This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all.</p> <p>This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.</p> https://vulnerability.circl.lu/vuln/cve-2026-46041