LiveActive security incident?Get immediate response
CVE Record

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 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.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel reliability bug in the Greybus BeaglePlay driver. Under specific driver activity, the kernel can try to sleep while holding a spinlock, which is illegal and may trigger a scheduling-while-atomic kernel bug. Business impact is most relevant where affected kernels and this driver path are used.

Executive priority

Handle through normal kernel patch management unless BeaglePlay or Greybus functionality is production-critical. Escalate priority if affected systems show kernel BUG messages or availability risk. Evidence is incomplete for broad emergency treatment.

Technical view

In gb-beagleplay, hdlc_append() could call usleep_range() while tx_producer_lock was held through hdlc_tx_frames(). The fix moves buffer-space waiting before taking the spinlock, then rechecks capacity under lock and enqueues complete frames atomically. CodeQL and review found the issue.

Likely exposure

Exposure is likely limited to Linux systems that include and exercise the greybus gb-beagleplay HDLC transmit path. The CVE lists Linux as affected but has irregular version data, so confirm against your distribution kernel and the linked stable commits.

Exploitation context

No provided source reports active exploitation, and the CVE is not in KEV. The source does not define a remote attack path, required privileges, or practical exploitability. Treat this primarily as a kernel stability and denial-of-service risk until vendor scoring clarifies impact.

Researcher notes

The core issue is sleep-in-atomic context in the HDLC transmit buffer path. The fix changes ordering: precompute worst-case encoded length, wait outside the lock, then revalidate space under spinlock before writing. Public sources do not establish attacker control or exploit primitives.

Mitigation direction

  • Check Linux vendor or distribution advisories for CVE-2026-46041 coverage.
  • Update to a kernel build containing the referenced stable fixes.
  • Prioritize systems using BeaglePlay, Greybus, or gb-beagleplay functionality.
  • If patching is delayed, assess whether the affected driver is present and needed.
  • Track vendor CVSS and affected-version clarification when published.

Validation and detection

  • Inventory kernels and confirm whether gb-beagleplay support is built or loaded.
  • Compare deployed kernel source or package changelog against the referenced stable commits.
  • Review logs for scheduling-while-atomic or related kernel BUG messages.
  • Confirm patched behavior through vendor package metadata or source diff review.
Prepared
Confidence
medium
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2026-46041 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
5Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxec558bbfea671ac020a6dc6be8bf8f0ee556cce0, ec558bbfea671ac020a6dc6be8bf8f0ee556cce0, ec558bbfea671ac020a6dc6be8bf8f0ee556cce0, ec558bbfea671ac020a6dc6be8bf8f0ee556cce0unaffected
LinuxLinux6.7, 0, 6.12.86, 6.18.27, 7.0.4, 7.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.