CVE-2026-90098 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: fix sleep in atomic context in MAC table access
sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context.
Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain.
Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for the Microchip SparX-5 Ethernet switch contains a critical concurrency violation that triggers a sleeping function call from an invalid atomic context. This vulnerability arises within the network device operation to set receive modes, specifically in the sparx5_set_rx_mode() function. When this routine is invoked, it executes while holding the netif_addr_lock_bh spinlock, which places the execution path into an atomic context where blocking operations are strictly prohibited by kernel locking rules. The function iterates over the multicast address list using __dev_mc_sync(), and for each address, it calls sparx5_mc_sync() or sparx5_mc_unsync(). These helper functions subsequently invoke sparx5_mact_learn() or sparx5_mact_forget() to update the hardware MAC table.
The core technical flaw lies in the implementation of these MAC table synchronization functions. They attempt to acquire sparx5->lock, which is defined as a mutex. Mutexes are sleeping locks that may cause the current thread to block and yield CPU time if the lock is contended or during initialization sequences involving completion waits. Furthermore, after acquiring the lock, the driver polls the hardware MAC access command register using readx_poll_timeout(), a macro that can also introduce delays and potential blocking behavior depending on its configuration and implementation details. Since this entire sequence occurs while holding netif_addr_lock_bh, any attempt to sleep violates kernel preemption rules, leading to immediate detection by debugging subsystems such as CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP.
The operational impact of this vulnerability is severe for system stability when the affected conditions are met. If a user attempts to open a network interface associated with the SparX-5 device while holding address locks, the kernel will detect the illegal sleep attempt and trigger a BUG() condition. This results in an immediate kernel panic or oops, effectively crashing the host machine or causing significant service disruption for any processes relying on that network interface. The call trace confirms the violation occurs during __dev_open(), which is commonly triggered when bringing up a network link, making this vulnerability easily exploitable through standard administrative actions rather than requiring complex attack vectors.
To resolve this issue, the driver was refactored to utilize the ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 of the Linux kernel networking subsystem. This new asynchronous mechanism allows the receive mode update logic to be deferred and executed from process context rather than atomic context. By moving the execution into a workqueue or similar async handler, the driver can safely acquire mutexes and perform blocking operations like polling hardware registers without violating locking constraints. This architectural change aligns with modern kernel networking best practices that separate immediate lock-protected tasks from longer-running hardware interaction sequences.
From a vulnerability classification perspective, this issue maps to CWE-674: Uncontrolled Operation in Critical Loop or CWE-833: Deadlock, although the primary manifestation here is an illegal sleep in atomic context which falls under CWE-1205: Signal Handler Race Condition if viewed broadly as concurrency errors, but more accurately aligns with improper locking usage often categorized under general resource management flaws. In terms of ATT&CK mapping, this does not represent a direct attack vector for exploitation by external actors but rather represents an internal stability flaw that could be leveraged in denial-of-service scenarios if triggered intentionally through rapid interface state changes. Mitigation involves applying the kernel patch that implements the async callback mechanism and ensuring systems are updated to versions containing commit 3554b4345d85 or later where applicable driver updates are available. Administrators should also ensure their kernels have debugging locks enabled in development environments to catch such concurrency issues early before deployment.