Bug 2482086 (CVE-2026-46041)

Summary: CVE-2026-46041 kernel: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's greybus subsystem. This vulnerability occurs when a function attempts to pause its execution while holding a critical system lock, a condition known as 'sleep in atomic context'. This improper handling can lead to a system crash, making the system unavailable and resulting in a Denial of Service (DoS).
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-27 15:10:39 UTC
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.