CVE-2026-46041

What it actually does

This is a local Linux kernel denial-of-service flaw in the Greybus BeaglePlay HDLC transmit path. The vulnerable code can call a sleeping function while holding a spinlock, which violates kernel locking rules and can trigger a "BUG: scheduling while atomic" condition. Depending on kernel configuration and runtime settings, this may lead to a kernel warning, task instability, driver malfunction, system hang, or kernel panic. The impact is availability only; the provided details do not indicate confidentiality or integrity compromise.

Why it matters to the business

Systems using affected Linux kernels with the Greybus BeaglePlay driver enabled may be vulnerable to local disruption. A user or process with local access capable of exercising the affected driver path could cause outages, reboots, or instability on impacted devices. The risk is moderated by the local-access requirement, low EPSS score, absence from the CISA KEV catalog, and no known mature public exploit in the supplied data, but it still matters for embedded, development, lab, or production devices where BeaglePlay/Greybus functionality is enabled and uptime is important.

How an attack unfolds

An attacker first obtains local access to a system running an affected Linux kernel where the Greybus BeaglePlay driver path is present and reachable. The attacker then triggers Greybus HDLC transmit activity in a way that causes the transmit buffer handling code to wait for buffer space while the transmit producer spinlock is held. Because the kernel attempts to sleep in atomic context, it can emit a scheduling-while-atomic bug and destabilize the kernel. On systems configured to panic on kernel warnings or bugs, this can escalate from a warning to a full system crash or reboot. There is no indication in the supplied data of remote exploitation, privilege escalation, data theft, ransomware use, or active exploitation by named threat actors.

How to fix it

Apply a Linux kernel update that includes the upstream or distribution backport fix for the Greybus BeaglePlay HDLC transmit locking bug. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs for the relevant distribution, device vendor, or long-term-support kernel branch to identify the corrected build. Where immediate patching is not possible, reduce exposure by disabling or unloading the Greybus BeaglePlay driver if it is not required, removing unused Greybus-related device access from untrusted users, limiting local shell access, and monitoring for kernel instability. If systems are configured to panic on warnings, review whether that setting is operationally required; changing it may reduce outage impact but does not remediate the vulnerability.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and package build against the vendor advisory or kernel changelog containing the Greybus BeaglePlay fix. Check whether Greybus BeaglePlay support is enabled or loaded using kernel configuration, loaded-module, and device inventory checks. Validate that the vulnerable code path no longer produces "BUG: scheduling while atomic" under legitimate Greybus BeaglePlay transmit activity in a controlled test environment. For source-based builds, confirm that the fix moves the buffer-space sleep/wait out of the spinlock-protected append path and rechecks buffer space after acquiring the lock.

Typical attack path

1. Gain local access to an affected Linux system with the Greybus BeaglePlay driver enabled or loaded.
2. Identify that the vulnerable Greybus/HDLC transmit path is reachable from available local interfaces or workloads.
3. Generate or induce Greybus HDLC transmit activity that stresses the circular transmit buffer.
4. Trigger the code path where buffer-space waiting occurs while a spinlock is held.
5. Cause the kernel to report "BUG: scheduling while atomic" and potentially hang, panic, or reboot depending on configuration.

How to detect it

Look for evidence of prior kernel instability associated with the Greybus BeaglePlay transmit path. Useful sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore artifacts, system reboot records, and kernel oops/panic reports collected by tools such as ABRT, apport, systemd-coredump, or vendor telemetry. Search for "BUG: scheduling while atomic" near stack traces containing Greybus, BeaglePlay, HDLC transmit, hdlc_tx_frames, hdlc_append, hdlc_append_tx_frame, or tx_producer_lock. Also review unexpected reboot events occurring shortly after Greybus driver messages. These indicators can show that the vulnerable condition occurred, but they may not conclusively prove malicious exploitation because legitimate driver activity or testing can trigger the same failure mode.

• BUG: scheduling while atomic
• gb-beagleplay
• greybus
• hdlc_tx_frames
• hdlc_append
• hdlc_append_tx_frame
• hdlc_append_tx_u8
• tx_producer_lock
• kernel BUG
• Kernel panic
• Oops:
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/sys/kernel/panic_on_warn

What your security team should do

• Inventory Linux systems and embedded devices that use BeaglePlay, Greybus, or related kernel drivers.
• Prioritize patching for systems where the Greybus BeaglePlay driver is enabled and local users, containers, development workloads, or untrusted processes can interact with the affected path.
• Track distribution and device-vendor kernel advisories for the fixed build because no exact fixed versions were supplied.
• Temporarily disable or unload unused Greybus BeaglePlay functionality where operationally feasible.
• Review kernel panic-on-warning settings on high-availability systems to understand whether this flaw could cause full outages.
• Add monitoring for kernel messages indicating scheduling while atomic, Greybus HDLC transmit failures, kernel oopses, panics, and unexpected reboots.
• Preserve kernel logs and crash dumps for any suspected incidents to distinguish this condition from unrelated hardware or driver instability.