Answer in brief
CVE-2026-31531 records a Unknown severity vulnerability in ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=430a049190de3c9e219f43084de9f1122da04570 <18a4543c1750f96be63e349936d2dfdcb360b2dc || >=430a049190de3c9e219f43084de9f1122da04570 <615517f3f8d53b0cf41507c7599971e17adfdfa5 || >=430a049190de3c9e219f43084de9f1122da04570 <40bd39e383a0478fd5c221f393df05fd9d70cfbc || >=430a049190de3c9e219f43084de9f1122da04570 <635038fe19db391117e66b46bdc2b6e447ac801d || >=430a049190de3c9e219f43084de9f1122da04570 <14cf0cd35361f4e94824bf8a42f72713d7702a73 | 18a4543c1750f96be63e349936d2dfdcb360b2dc, 615517f3f8d53b0cf41507c7599971e17adfdfa5, 40bd39e383a0478fd5c221f393df05fd9d70cfbc, 635038fe19db391117e66b46bdc2b6e447ac801d, 14cf0cd35361f4e94824bf8a42f72713d7702a73 |
| Linux/Linuxgeneric | 5.3 | Not reported |
Published upstream
Apr 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 21, 2026
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
Quoted source text, attributed separately from HOL analysis.