CVE-2026-45840 in Linux
Sumário
de VulDB • 30/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
openvswitch: limitar o tamanho do array de PIDs de upcall e pré-alocar as respostas vport
Os auxiliares de resposta netlink vport alocam um skb de tamanho fixo com nlmsg_new(NLMSG_DEFAULT_SIZE, ...) mas serializam o array completo de PIDs de upcall via ovs_vport_get_upcall_portids(). Como ovs_vport_set_upcall_portids() aceita qualquer múltiplo não nulo de sizeof(u32) sem limite superior, um usuário com CAP_NET_ADMIN pode instalar um array de PIDs grande o suficiente para estourar o buffer de resposta, fazendo com que nla_put() falhe com -EMSGSIZE e acionando BUG_ON(err < 0). Em sistemas com namespaces de usuário não privilegiados habilitados (por exemplo, padrão do Ubuntu), isso é alcançável via unshare -Urn já que as operações de mutação de vport OVS usam GENL_UNS_ADMIN_PERM.
Kernel BUG em net/openvswitch/datapath.c:2414! Oops: opcode inválido: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 65 Comm: poc Não modificado 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Rastreamento de chamada:
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Kernel panic - not syncing: Exceção fatal
Rejeitar tentativas de definir mais PIDs do que nr_cpu_ids em ovs_vport_set_upcall_portids(), e pré-computar o tamanho de resposta no pior caso em ovs_vport_cmd_msg_size() com base nesse limite, de forma semelhante ao existente ovs_dp_cmd_msg_size(). nr_cpu_ids corresponde ao limite já usado pela configuração de despacho por CPU no lado do datapath (ovs_dp_cmd_fill_info() serializa no máximo nr_cpu_ids PIDs), mantendo assim a consistência entre os dois lados.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.