PT-2026-34657 · Linux · Linux
Published
2026-04-23
·
Updated
2026-04-23
·
CVE-2026-31531
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
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)
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
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux