CVE-2026-46041
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk6th percentile - higher than 6% of all known CVEs
Summary
A vulnerability has been identified in the Linux kernel related to the hdlc_tx_frames() function, which calls usleep_range() in an atomic context, which is illegal. The issue has been resolved by moving the buffer-space wait outside the spinlock context.
Risk Assessment
Organizations may experience performance and stability issues as improper atomic context management can lead to scheduling errors. This may affect the operation of applications relying on this component.
Recommendation
It is recommended to update the Linux kernel to a version that includes the fix for this vulnerability to avoid issues related to improper atomic context management.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() 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() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/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 hdlc_append() and into hdlc_tx_frames(), 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.