CVE-2026-90098: net: sparx5: fix sleep in atomic context in MAC table access
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: fix sleep in atomic context in MAC table access
sparx5setrxmode() runs with netifaddrlockbh held and iterates dev->mc via devmcsync(), which per address calls sparx5mcsync() / sparx5mcunsync() -> sparx5mactlearn() / sparx5mactforget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readxpolltimeout(). A mutex may block, which is not allowed from atomic context.
Convert the driver to the new .ndosetrxmodeasync callback introduced in commit 3554b4345d85 ("net: introduce ndosetrxmodeasync and netdevrxmodework"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain.
Observed with CONFIGPROVELOCKING, CONFIGDEBUGSPINLOCK, CONFIGDEBUGMUTEXES and CONFIGDEBUGATOMICSLEEP enabled:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 217, name: ip preemptcount: 201, expected: 0 Call trace: mightresched+0x144/0x248 mightsleep+0x48/0x7c mutexlock+0x74/0x850 mutexlocknested+0x24/0x30 sparx5mactlearn+0x78/0x100 sparx5mcsync+0x40/0x54 hwaddrsyncdev+0xc4/0x170 sparx5setrxmode+0x4c/0x58 devsetrxmode+0x64/0xa4 devopen+0x1ec/0x26c
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 3554b4345d85 - Configuration
Ensure the debug/proving configuration that detects this class of bug (CONFIG_PROVE_LOCKING) is enabled so locking/sleep-in-atomic issues are caught during testing.
Linux kernel CONFIG_PROVE_LOCKING = enabled - Configuration
Ensure CONFIG_DEBUG_MUTEXES is enabled to catch sleeping mutex usage in invalid contexts.
Linux kernel CONFIG_DEBUG_MUTEXES = enabled - Configuration
Ensure CONFIG_DEBUG_ATOMIC_SLEEP is enabled to detect sleeping from atomic context.
Linux kernel CONFIG_DEBUG_ATOMIC_SLEEP = enabled
Event History
Frequently Asked Questions
Which systems should be prioritized for review?
Prioritize Linux systems using the sparx5 driver where receive-mode changes cause multicast MAC address synchronization. The issue is in MAC table access performed during the driver's multicast sync and unsync operations.
How can I recognize this issue in logs or debugging output?
The reported symptom is a “sleeping function called from invalid context” warning while attempting to lock a mutex, with a call trace involving sparx5_set_rx_mode(), sparx5_mc_sync() or sparx5_mc_unsync(), and sparx5_mact_learn() or sparx5_mact_forget(). It was observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES, and CONFIG_DEBUG_ATOMIC_SLEEP enabled; not seeing the warning does not establish that the system is unaffected.