CVE-2026-46041: Linux Kernel Race Condition Vulnerability

CVE-2026-46041 Overview

CVE-2026-46041 is a Linux kernel vulnerability in the greybusgb-beagleplay driver. The flaw resides in the hdlc_tx_frames() transmit path, where hdlc_append() invokes usleep_range() while the tx_producer_lock spinlock is held. Sleeping while holding a spinlock violates kernel locking rules and triggers a BUG: scheduling while atomic condition. The issue was identified through CodeQL interprocedural sleep-in-atomic static analysis and subsequent code review. The kernel maintainers resolved the bug by relocating the buffer-space wait outside the spinlock-protected region in hdlc_tx_frames().

Critical Impact
Local triggering of the affected code path can cause kernel scheduling violations, leading to denial of service on systems running the gb-beagleplay greybus host driver.

Affected Products

Linux kernel versions containing the drivers/greybus/gb-beagleplay HDLC transmit logic prior to the fix
BeaglePlay platforms using greybus over HDLC
Downstream distributions shipping affected stable kernels

Discovery Timeline

2026-05-27 - CVE-2026-46041 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-46041

Vulnerability Analysis

The gb-beagleplay driver implements High-Level Data Link Control (HDLC) framing for greybus transport. The transmit path hdlc_tx_frames() calls helper routines such as hdlc_append_tx_frame() and hdlc_append_tx_u8(), which in turn invoke hdlc_append(). These helpers run with tx_producer_lock, a spinlock, held to serialize access to the circular transmit buffer.

Inside hdlc_append(), when the circular buffer lacks space, the code calls usleep_range() to wait for the consumer to drain bytes. The Linux scheduler forbids sleeping while a spinlock is held because spinlocks disable preemption and may run in interrupt-adjacent contexts. Hitting this path triggers BUG: scheduling while atomic, producing kernel warnings and potentially destabilizing the system.

This is a kernel locking defect classified as a sleep-in-atomic-context bug. It is a reliability and denial-of-service issue rather than a memory corruption flaw.

Root Cause

The root cause is the placement of a sleeping primitive (usleep_range()) inside a critical section protected by a spinlock. The append helpers were not designed to release the lock before waiting on buffer availability, mixing blocking and non-blocking synchronization semantics.

Attack Vector

The issue requires execution of the greybus HDLC transmit path under buffer-full conditions on a BeaglePlay system. A local workload that saturates the greybus transmit queue can trigger the sleep-in-atomic condition. There is no indication of remote exploitability, privilege escalation, or memory disclosure tied to this CVE.

The upstream fix restructures hdlc_tx_frames() as follows: pre-calculate the worst-case encoded frame length, wait outside the lock until sufficient space is available while kicking the TX consumer work, then acquire tx_producer_lock, re-verify space, and write the frame atomically. Refer to the kernel commit 9f2b87bcdfed and related stable backports for the exact diff.

Detection Methods for CVE-2026-46041

Indicators of Compromise

Kernel log entries containing BUG: scheduling while atomic referencing hdlc_append, hdlc_tx_frames, or gb_beagleplay
Stack traces in dmesg showing usleep_range invoked from within hdlc_append_tx_frame or hdlc_append_tx_u8
Soft lockup or scheduler warnings on BeaglePlay devices under greybus load

Detection Strategies

Audit running kernel versions on BeaglePlay and greybus-enabled hosts against the patched stable commits referenced in the kernel.org advisory
Enable CONFIG_DEBUG_ATOMIC_SLEEP in test kernels to surface sleep-in-atomic call sites during validation
Run CodeQL or equivalent static analyzers with sleep-in-atomic queries against custom kernel trees that include the gb-beagleplay driver

Monitoring Recommendations

Forward dmesg and journald kernel messages to a centralized logging pipeline and alert on scheduling while atomic patterns
Track kernel package versions across fleet inventory to confirm patched builds are deployed
Monitor system stability metrics (panics, soft lockups, watchdog resets) on embedded devices running greybus workloads

How to Mitigate CVE-2026-46041

Immediate Actions Required

Apply the stable kernel updates that include commits 51667fe2d929, 6b526dca0966, 9f2b87bcdfed, and b2801647c203 from the upstream gb-beagleplay fix series
Rebuild and redeploy custom kernels for BeaglePlay or greybus-enabled platforms with the patched drivers/greybus/gb-beagleplay sources
Validate fixed kernels under CONFIG_DEBUG_ATOMIC_SLEEP to confirm the warning is eliminated

Patch Information

Upstream stable trees received the fix across multiple commits. See the primary commit 9f2b87bcdfed, commit 51667fe2d929, commit 6b526dca0966, and commit b2801647c203. The fix moves the buffer-space wait out of the locked region in hdlc_tx_frames() so that usleep_range() is never called while tx_producer_lock is held.

Workarounds

Avoid loading the gb-beagleplay driver on systems that do not require greybus over HDLC until patched kernels are deployed
Reduce greybus transmit pressure to lower the likelihood of buffer-full conditions that exercise the vulnerable path
Restrict local access on affected embedded devices to trusted operators while the patch is rolled out

bash

# Verify whether the gb-beagleplay module is loaded
lsmod | grep gb_beagleplay

# Temporarily blacklist the driver until a patched kernel is installed
echo 'blacklist gb_beagleplay' | sudo tee /etc/modprobe.d/blacklist-gb-beagleplay.conf
sudo update-initramfs -u

# Confirm patched kernel package is installed (example for Debian-based systems)
dpkg -l | grep linux-image