Description
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.
Published: 2026-05-27
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The bug occurs in the Linux kernel's greybus driver when the hdlc_append() function sleeps while holding a spinlock. Sleeping in an atomic context triggers a BUG message and can cause the kernel to panic, leading to a system crash or unstable behavior. It represents a serious internal kernel consistency issue rather than a traditional user‑level exploitable flaw, but it can impact availability and system integrity when the driver is actively used.

Affected Systems

All Linux kernel releases that include the greybus gb-beagleplay driver prior to the commit that fixes the sleep issue are affected. The vulnerability applies to the generic Linux kernel, as reflected by the CPE string for linux_kernel, and impacts any distribution that has not applied the patch. No specific version numbers are listed, so all prior revisions with the buggy code are potentially vulnerable.

Risk and Exploitability

The description indicates that sleeping while a spinlock is held can trigger a BUG message and potentially cause a kernel panic. It is inferred that practical exploitation would require local or privileged code that forces the driver to generate heavy frame traffic and exhaust the buffer, thereby triggering the sleep. No confirmed exploits are documented, and the EPSS score is unavailable; however, the lack of a KEV listing suggests that the vulnerability is not currently actively exploited. The risk is primarily to availability, as a kernel panic can result in a reboot or halt. A patch that moves the sleep outside the critical section prevents the BUG and removes the risk.

Generated by OpenCVE AI on May 28, 2026 at 02:16 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel update that includes the greybus driver fix, following the commits linked in the advisory
  • If a distribution update is not available, backport or cherry‑pick the relevant kernel commits and rebuild the kernel
  • After updating, restart the system to ensure the patched driver is in use
  • Verify that the gb-beagleplay module is unloaded before upgrading if it is not required, to prevent accidental loading of the buggy code

Generated by OpenCVE AI on May 28, 2026 at 02:16 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 28 May 2026 00:15:00 +0000


Wed, 27 May 2026 20:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description 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.
Title greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T12:56:54.418Z

Reserved: 2026-05-13T15:03:33.094Z

Link: CVE-2026-46041

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:23.520

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-46041

cve-icon Redhat

Severity :

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-46041 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T02:30:04Z

Weaknesses