CVE-2026-23203
Race Condition in Linux Kernel CPSW netdev RX Mode Handling
Publication date: 2026-02-14
Last updated on: 2026-03-19
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | 6.19 |
| linux | linux_kernel | From 6.17 (inc) to 6.18.10 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability involves the Linux kernel's network subsystem, specifically the cpsw_new driver and its handling of the ndo_set_rx_mode callback.
A recent change removed the RTNL lock for certain IPv6 multicast operations, which caused a call trace and assertion failure because cpsw_ndo_set_rx_mode expects the RTNL lock to be held when calling vlan_for_each().
Since the locking behavior is inconsistent and modifying vlan_for_each() to work without the RTNL lock is complex, the fix was to move the processing into a work queue to avoid the locking issue.
How can this vulnerability impact me? :
This vulnerability can cause kernel warnings and assertion failures leading to instability or crashes in the network stack on affected devices, such as the BeagleBone Black.
Such instability could disrupt network functionality, potentially causing denial of service or degraded performance in systems relying on the affected Linux kernel network drivers.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a kernel warning and call trace related to the RTNL lock assertion failure in the vlan_core.c file. Specifically, you may observe messages similar to the following in your system logs or dmesg output:
- WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124
- RTNL: assertion failed at net/8021q/vlan_core.c (236)
- Call trace involving cpsw_add_mc_addr, __dev_mc_add, igmp6_group_added, and ipv6_setsockopt
To detect this on your system, you can check the kernel logs using commands such as:
- dmesg | grep vlan_core.c
- journalctl -k | grep vlan_core.c
- grep -i 'RTNL: assertion failed' /var/log/kern.log
Monitoring these logs for the specific warning and call trace will help identify if the vulnerability is triggered on your system.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is resolved by changing the execution context of the ndo_set_rx_mode callback to a work queue instead of executing it directly, which avoids the RTNL lock assertion failure.
Immediate mitigation steps include:
- Update your Linux kernel to a version that includes the fix implementing the work queue execution for cpsw_new's ndo_set_rx_mode callback.
- Avoid running network operations or configurations that trigger the ndo_set_rx_mode callback on affected hardware or kernel versions until patched.
- Monitor kernel logs for the warning messages to detect if the issue occurs.
Since the fix involves kernel code changes, applying the updated kernel is the recommended and effective mitigation.