CVE-2026-31531: ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()

In the Linux kernel, the following vulnerability has been resolved:

ipv4: nexthop: allocate skb dynamically in rtmgetnexthop()

When querying a nexthop object via RTMGETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSGGOODSIZE. 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 rtmgetnexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtmgetnexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlinkrcvmsg (net/core/rtnetlink.c:6989) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) syssendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) syssendmsg (net/socket.c:2641) syssendmsg (net/socket.c:2671) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Fix this by allocating the size dynamically using nhnlmsgsize() and using nlmsgnew(), this is consistent with nexthopnotify() behavior. In addition, adjust nhnlmsgsizegrp() so it calculates the size needed based on flags passed. While at it, also add the size of NHAFDB 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:

addattrl ERROR: message exceeded bound of 1048