CVE-2026-31531 in Linux
Zusammenfassung
von VulDB • 20.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ipv4: nexthop: dynamische skb-Allokation in rtm_get_nexthop()
Bei der Abfrage eines Nexthop-Objekts über RTM_GETNEXTHOP allokiert der Kernel derzeit einen skb fester Größe unter Verwendung von NLMSG_GOODSIZE. Dies ist zwar für einzelne Nexthops und kleine Equal-Cost Multi-Path-Gruppen ausreichend, aber diese feste Allokation schlägt bei großen Nexthop-Gruppen, wie z. B. 512 Nexthops, fehl.
Dies führt zu folgender Warnung (Warning Splat):
WARNING: net/ipv4/nexthop.c:3395 bei rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...]
RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...]
Call Trace: 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)
Die Behebung erfolgt durch die dynamische Allokation der Größe unter Verwendung von nh_nlmsg_size() und nlmsg_new(), was konsistent mit dem Verhalten von nexthop_notify() ist. Darüber hinaus wird nh_nlmsg_size_grp() so angepasst, dass es die benötigte Größe basierend auf den übergebenen Flags berechnet. Dabei wird auch die Größe von NHA_FDB für die Nexthop-Gruppengrößenberechnung hinzugefügt, da diese ebenfalls fehlte.
Dieser Fehler kann nicht über iproute2 reproduziert werden, da die Gruppengröße derzeit begrenzt ist und der Befehl wie folgt fehlschlägt:
addattr_l ERROR: Nachricht hat die Grenze von 1048 überschritten
If you want to get best quality of vulnerability data, you may have to visit VulDB.