CVE-2026-46041: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()
In the Linux kernel, the following vulnerability has been resolved:
greybus: gb-beagleplay: fix sleep in atomic context in hdlctxframes()
hdlcappend() calls usleeprange() to wait for circular buffer space, but it is called with txproducerlock (a spinlock) held via hdlctxframes() -> hdlcappendtxframe()/hdlcappendtxu8()/etc. Sleeping while holding a spinlock is illegal and can trigger "BUG: scheduling while atomic".
Fix this by moving the buffer-space wait out of hdlcappend() and into hdlctxframes(), before the spinlock is acquired. The new flow:
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.
This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all.
This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In greybus hdlc_tx_frames(), pre-calculate the worst-case encoded frame length and move the buffer-space wait (including usleep_range()) out of hdlc_append() and before acquiring tx_producer_lock; wait until enough space is available, then acquire the spinlock, re-verify space, and enqueue the entire frame atomically.