CVE-2022-49812 in Linux
Sumário
de VulDB • 03/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bridge: switchdev: Correção de vazamentos de memória ao alterar o protocolo VLAN
O driver bridge pode descarregar as VLANs para o hardware subjacente, seja via switchdev ou via o driver 8021q. Quando o primeiro método é utilizado, a VLAN é marcada no driver bridge com a flag privada 'BR_VLFLAG_ADDED_BY_SWITCHDEV'.
Para evitar os vazamentos de memória mencionados no commit citado, o driver bridge tentará excluir uma VLAN através do driver 8021q se a VLAN não estiver marcada com a flag anteriormente mencionada.
Quando o protocolo VLAN da bridge muda, os drivers switchdev são notificados através do atributo 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL', mas o driver 8021q também é chamado para adicionar as VLANs existentes com o novo protocolo e removê-las com o protocolo antigo.
No caso em que as VLANs foram descarregadas via switchdev, o comportamento acima é tanto redundante quanto defeituoso. Redundante porque as VLANs já estão programadas no hardware e os drivers que suportam a alteração do protocolo VLAN (atualmente apenas mlx5) alteram o protocolo mediante a notificação do atributo switchdev. Defeituoso porque o driver 8021q é chamado apesar dessas VLANs estarem marcadas com 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Isso leva a vazamentos de memória [1] quando as VLANs são excluídas.
Correção: não chamar o driver 8021q para VLANs que já foram programadas via switchdev.
[1]
objeto não referenciado 0xffff8881f6771200 (tamanho 256): comm "ip", pid 446855, jiffies 4298238841 (idade 55.240s) dump hexadecimal (primeiros 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750
[<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920
[<000000000632b56f>] br_changelink+0x3d6/0x13f0
[<0000000089d25f04>] rtnl_newlink+0x538/0x1000
[<000000001c2241c0>] rtnetlink_rcv_msg+0x336/0xa00
[<000000001c2241c0>] rtnetlink_rcv_msg+0x336/0xa00
[<0000000010588814>] netlink_rcv_skb+0x11d/0x340
[<0000000010588814>] netlink_rcv_skb+0x11d/0x340
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicam
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.