LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53855: net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver remove

In the Linux kernel, the following vulnerability has been resolved: net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver remove When the tagging protocol in current use is "ocelot-8021q" and we unbind the driver, we see this splat: $ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbind mscc_felix 0000:00:00.5 swp0: left promiscuous mode sja1105 spi2.0: Link is Down DSA: tree 1 torn down mscc_felix 0000:00:00.5 swp2: left promiscuous mode sja1105 spi2.2: Link is Down DSA: tree 3 torn down fsl_enetc 0000:00:00.2 eno2: left promiscuous mode mscc_felix 0000:00:00.5: Link is Down ------------[ cut here ]------------ RTNL: assertion failed at net/dsa/tag_8021q.c (409) WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0 Modules linked in: CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771 pc : dsa_tag_8021q_unregister+0x12c/0x1a0 lr : dsa_tag_8021q_unregister+0x12c/0x1a0 Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50 ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ RTNL: assertion failed at net/8021q/vlan_core.c (376) WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0 CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771 pc : vlan_vid_del+0x1b8/0x1f0 lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50 DSA: tree 0 torn down This was somewhat not so easy to spot, because "ocelot-8021q" is not the default tagging protocol, and thus, not everyone who tests the unbinding path may have switched to it beforehand. The default felix_tag_npi_teardown() does not require rtnl_lock() to be held.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This is a narrow Linux kernel bug in the DSA Ocelot/Felix switch-driver teardown path. When a non-default tagging mode is used, removing the driver can call cleanup code without the required network lock, causing kernel warnings. The provided sources do not show data theft, remote attack, privilege escalation, or active exploitation.

Executive priority

Treat this as targeted maintenance unless your environment uses affected Linux switch-driver paths. The business urgency is lower than broadly exploitable kernel issues, but network or embedded Linux platforms with this hardware path should be patched through normal vendor channels.

Technical view

The issue is in Linux net/dsa ocelot handling: dsa_tag_8021q_unregister() was called during driver removal without rtnl_lock() when using the ocelot-8021q tagging protocol. The observed failure is an RTNL assertion splat during teardown. Kernel stable commits are referenced as the resolution.

Likely exposure

Exposure appears limited to Linux systems using the DSA Ocelot/Felix driver path with ocelot-8021q tagging and driver removal or unbind activity. General Linux deployments without that hardware, driver, or tagging mode are unlikely to be exposed based on the provided evidence.

Exploitation context

The source bundle does not report active exploitation, and KEV is false. The described trigger is a driver unbind/removal scenario with a non-default tagging protocol. The evidence shows kernel warning/assertion behavior, not a documented remote exploit path.

Researcher notes

The public evidence is limited to the kernel fix description and stable commit references. No CVSS, CWE, exploitability analysis, or product-specific advisory is included. The root issue is lock-context correctness during DSA tag 8021q unregister on teardown.

Mitigation direction

  • Check Linux vendor advisories for patched kernels containing the referenced stable commits.
  • Prioritize updates on systems using Ocelot/Felix DSA switching with ocelot-8021q tagging.
  • Avoid unnecessary driver unbind or removal operations on potentially affected production systems.
  • Use vendor-supported kernel packages rather than manually backporting unless internally validated.

Validation and detection

  • Inventory Linux systems using DSA Ocelot/Felix switch drivers.
  • Confirm whether ocelot-8021q tagging is configured or available on those systems.
  • Compare running kernel builds against vendor guidance and referenced stable fixes.
  • Review kernel logs for RTNL assertion warnings during switch driver teardown.
  • Validate fixes in a lab before production rollout where network appliances are involved.
Prepared
Confidence
medium
Sources
5

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-53855 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
4Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux7c83a7c539abe9f980996063ac20532a7a7f6eb1, 7c83a7c539abe9f980996063ac20532a7a7f6eb1, 7c83a7c539abe9f980996063ac20532a7a7f6eb1unaffected
LinuxLinux5.12, 0, 6.1.46, 6.4.11, 6.5affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.