Katalog CVE

CVE-2026-31531

ŚrednieCVSS 5.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.17%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linux w funkcji rtm_get_nexthop() podczas odpytania obiektu nexthop przez RTM_GETNEXTHOP używano stałego rozmiaru bufora skb (NLMSG_GOODSIZE), co jest niewystarczające dla dużych grup nexthop (np. 512 elementów). Prowadzi to do ostrzeżenia w net/ipv4/nexthop.c i potencjalnych problemów z alokacją. Poprawka polega na dynamicznej alokacji rozmiaru za pomocą nh_nlmsg_size() i nlmsg_new() oraz uwzględnieniu flag i rozmiaru NHA_FDB w obliczeniach.

Ocena ryzyka

Może powodować ostrzeżenia jądra, niepowodzenia zapytań o duże grupy nexthop i potencjalną niestabilność systemu przy operacjach sieciowych. Wpływa na niezawodność zarządzania routingiem w środowiskach z dużymi grupami ECMP.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-31531. Jeśli aktualizacja nie jest możliwa, unikaj odpytywania bardzo dużych grup nexthop przez RTM_GETNEXTHOP do czasu wdrożenia łatki.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops. This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too. This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows: addattr_l ERROR: message exceeded bound of 1048

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS