CVE-2022-49812 in Linux
Resumen
por MITRE • 2025-05-01
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bridge: switchdev: Fix memory leakage when Changing VLAN protocol El controlador del puente puede descargar VLAN al hardware subyacente mediante switchdev o el controlador 8021q. Cuando se utiliza el primero, la VLAN se marca en el controlador del puente con el indicador privado 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Para evitar las fugas de memoria mencionadas en la confirmación citada, el controlador del puente intentará eliminar una VLAN mediante el controlador 8021q si la VLAN no está marcada con el indicador mencionado anteriormente. Cuando cambia el protocolo VLAN del puente, se notifica a los controladores switchdev mediante el atributo 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL', pero también se llama al controlador 8021q para agregar las VLAN existentes con el nuevo protocolo y eliminarlas con el protocolo anterior. En caso de que las VLAN se descargaran mediante switchdev, el comportamiento anterior es redundante y presenta errores. Redundante porque las VLAN ya están programadas en el hardware y los controladores compatibles con el cambio de protocolo de VLAN (actualmente solo mlx5) cambian el protocolo al recibir la notificación del atributo switchdev. Presenta errores porque se llama al controlador 8021q a pesar de que estas VLAN están marcadas con 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Esto provoca fugas de memoria [1] al eliminar las VLAN. Se soluciona no llamando al controlador 8021q para las VLAN ya programadas mediante switchdev. [1] objeto sin referencia 0xffff8881f6771200 (tamaño 256): comm "ip", pid 446855, jiffies 4298238841 (edad 55.240s) volcado hexadecimal (primeros 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 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.