Skip to main content

Linux Kernel EUVDEUVD-2026-32422

| CVE-2026-46041 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-f857-h46c-q655
Linux Information Disclosure Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access with low privileges needed to interact with the greybus driver; impact is purely kernel availability (crash), with no confidentiality or integrity consequences.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 16, 2026 - 15:47 vuln.today
CVSS changed
Jun 16, 2026 - 15:22 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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.

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

AnalysisAI

Denial-of-service via kernel panic in the Linux kernel's greybus gb-beagleplay driver allows a local low-privileged user to crash the system by triggering an illegal sleep-in-atomic-context condition. The greybus HDLC TX path calls usleep_range() inside hdlc_append() while the tx_producer_lock spinlock is held, violating the fundamental Linux kernel rule that sleeping is forbidden in atomic context and triggering a 'BUG: scheduling while atomic' kernel oops. No public exploit has been identified at time of analysis, and EPSS at 0.02% (5th percentile) reflects the hardware-specific and local-access-only nature of this flaw. The input tag 'Information Disclosure' appears to be a misclassification - the actual impact is exclusively availability (kernel crash), consistent with the CVSS vector's A:H/C:N/I:N ratings.

Technical ContextAI

The greybus protocol stack enables hardware module communication on BeaglePlay single-board computers. The gb-beagleplay kernel module implements HDLC framing for TX operations via hdlc_tx_frames(), which acquires tx_producer_lock (a raw spinlock) and then calls hdlc_append_tx_frame(), hdlc_append_tx_u8(), and similar helpers that internally call hdlc_append(). hdlc_append() invokes usleep_range() when the circular TX buffer is full, waiting for space to become available. In the Linux kernel, acquiring a spinlock disables preemption (and in some contexts, interrupts), making any subsequent blocking call - including usleep_range() - a scheduling violation. When the scheduler detects that a task is attempting to sleep while in atomic context, it triggers 'BUG: scheduling while atomic', resulting in a kernel oops or full panic. CPE data (cpe:2.3:o:linux:linux_kernel) confirms this is a kernel-space issue present from the introduction of this driver at commit ec558bbfea671ac020a6dc6be8bf8f0ee556cce0, first appearing in Linux 6.7. The bug was identified via CodeQL interprocedural static analysis and manual code review.

RemediationAI

The primary fix is to upgrade to a patched kernel version: 6.12.86, 6.18.27, 7.0.4, or the 7.1-rc1 development release. Patch commits are available directly at kernel.org stable tree (https://git.kernel.org/stable/c/51667fe2d9294d66e0228b9f51d1f01b6680a641, https://git.kernel.org/stable/c/6b526dca0966f2370835765019a54319b78fca8d, https://git.kernel.org/stable/c/9f2b87bcdfed55145acbf932dc12f2c057145cad, https://git.kernel.org/stable/c/b2801647c203a38e013802e9e9616b5bfac64968). If immediate patching is not possible and BeaglePlay greybus functionality is not operationally required, blacklisting the gb-beagleplay module (add 'blacklist gb-beagleplay' to /etc/modprobe.d/) will prevent the driver from loading, eliminating the attack surface entirely - trade-off being loss of BeaglePlay hardware communication. No vendor advisory URL beyond the kernel.org stable commits has been identified in the available references.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

EUVD-2026-32422 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy