CVE-2026-23175

Source
https://cve.org/CVERecord?id=CVE-2026-23175
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23175.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-23175
Downstream
Published
2026-02-14T16:27:08.104Z
Modified
2026-02-14T19:59:18.188821Z
Summary
net: cpsw: Execute ndo_set_rx_mode callback in a work queue
Details

In the Linux kernel, the following vulnerability has been resolved:

net: cpsw: Execute ndosetrx_mode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstack_lvl from __warn+0xb8/0x11c __warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0x98 cpswaddmcaddr from __hwaddrrefsyncdev+0xc4/0xec __hwaddrrefsyncdev from __devmcadd+0x78/0x88 __devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from __ipv6devmc_inc+0x1fc/0x2f0 __ipv6devmc_inc from __ipv6sockmc_join+0x124/0x1b4 __ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosock_setsockopt from __sys_setsockopt+0x84/0xac _syssetsockopt from retfastsyscall+0x0/0x54

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver.

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23175.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
1767bb2d47b715a106287a8f963d9ec6cbab4e69
Fixed
488009aa62bb1217ea0624fd5108b79adef4e148
Fixed
0b8c878d117319f2be34c8391a77e0f4d5c94d79

Affected versions

v6.*
v6.16
v6.16-rc5
v6.16-rc6
v6.16-rc7
v6.17
v6.17-rc1
v6.17-rc2
v6.17-rc3
v6.17-rc4
v6.17-rc5
v6.17-rc6
v6.17-rc7
v6.18
v6.18-rc1
v6.18-rc2
v6.18-rc3
v6.18-rc4
v6.18-rc5
v6.18-rc6
v6.18-rc7
v6.18.1
v6.18.2
v6.18.3
v6.18.4
v6.18.5
v6.18.6
v6.18.7
v6.18.8
v6.18.9
v6.19-rc1
v6.19-rc2
v6.19-rc3
v6.19-rc4
v6.19-rc5
v6.19-rc6
v6.19-rc7

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23175.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.17.0
Fixed
6.18.10

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23175.json"