CVE-2022-50063
published 2025-06-18CVE-2022-50063: In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
3.8th percentile
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: suppress non-changes to the tagging protocol
The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn't know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).
This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we'll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops->teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.
The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.
echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging
echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
Call trace:
vcap_entry_get+0x24/0x124
ocelot_vcap_filter_del+0x198/0x270
felix_tag_8021q_vlan_del+0xd4/0x21c
dsa_switch_tag_8021q_vlan_del+0x168/0x2cc
dsa_switch_event+0x68/0x1170
dsa_tree_notify+0x14/0x34
dsa_port_tag_8021q_vlan_del+0x84/0x110
dsa_tag_8021q_unregister+0x15c/0x1c0
felix_tag_8021q_teardown+0x16c/0x180
felix_change_tag_protocol+0x1bc/0x230
dsa_switch_event+0x14c/0x1170
dsa_tree_change_tag_proto+0x118/0x1c0
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.2-1 (bookworm) | linux 6.0.2-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 7a29d220f4c0745a6d435dbd53c659fbde4998b6 < 8e432f157c3edc5a97a7244c666589a438f5e4d4 | 8e432f157c3edc5a97a7244c666589a438f5e4d4 |
| linux | linux | >= 7a29d220f4c0745a6d435dbd53c659fbde4998b6 < 4c46bb49460ee14c69629e813640d8b929e88941 | 4c46bb49460ee14c69629e813640d8b929e88941 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 5.19 < 5.19.4 | 5.19.4 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: net: dsa: felix: suppress non-changes to the tagging protocol
vendor_redhat·2025-06-18·CVSS 5.5
CVE-2022-50063 [MEDIUM] kernel: net: dsa: felix: suppress non-changes to the tagging protocol
kernel: net: dsa: felix: suppress non-changes to the tagging protocol
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: suppress non-changes to the tagging protocol
The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn't know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).
This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we'll get another call where proto_ops ==
old_proto_o
Debian
CVE-2022-50063: linux - In the Linux kernel, the following vulnerability has been resolved: net: dsa: f...
vendor_debian·2022·CVSS 5.5
CVE-2022-50063 [MEDIUM] CVE-2022-50063: linux - In the Linux kernel, the following vulnerability has been resolved: net: dsa: f...
In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn't know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we'll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For ex
OSV
CVE-2022-50063: In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa
osv·2025-06-18·CVSS 5.5
CVE-2022-50063 [MEDIUM] CVE-2022-50063: In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa
In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: suppress non-changes to the tagging protocol The way in which dsa_tree_change_tag_proto() works is that when dsa_tree_notify() fails, it doesn't know whether the operation failed mid way in a multi-switch tree, or it failed for a single-switch tree. So even though drivers need to fail cleanly in ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify() again, to restore the old tag protocol for potential switches in the tree where the change did succeeed (before failing for others). This means for the felix driver that if we report an error in felix_change_tag_protocol(), we'll get another call where proto_ops == old_proto_ops. If we proceed to act upon that, we may do unexpected things. For ex
GHSA
GHSA-vhwp-83w8-m7pm: In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: suppress non-changes to the tagging protocol
The way in which d
ghsa_unreviewed·2025-06-18
CVE-2022-50063 [MEDIUM] CWE-476 GHSA-vhwp-83w8-m7pm: In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: suppress non-changes to the tagging protocol
The way in which d
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: suppress non-changes to the tagging protocol
The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn't know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).
This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we'll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For
No detection rules found.
No public exploits indexed.
2025-06-18
Published