CVE-2026-31531 (GCVE-0-2026-31531)
Vulnerability from cvelistv5 – Published: 2026-04-23 11:12 – Updated: 2026-04-23 11:12
VLAI?
Title
ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
Summary
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
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
430a049190de3c9e219f43084de9f1122da04570 , < 615517f3f8d53b0cf41507c7599971e17adfdfa5
(git)
Affected: 430a049190de3c9e219f43084de9f1122da04570 , < 40bd39e383a0478fd5c221f393df05fd9d70cfbc (git) Affected: 430a049190de3c9e219f43084de9f1122da04570 , < 635038fe19db391117e66b46bdc2b6e447ac801d (git) Affected: 430a049190de3c9e219f43084de9f1122da04570 , < 14cf0cd35361f4e94824bf8a42f72713d7702a73 (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/nexthop.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "615517f3f8d53b0cf41507c7599971e17adfdfa5",
"status": "affected",
"version": "430a049190de3c9e219f43084de9f1122da04570",
"versionType": "git"
},
{
"lessThan": "40bd39e383a0478fd5c221f393df05fd9d70cfbc",
"status": "affected",
"version": "430a049190de3c9e219f43084de9f1122da04570",
"versionType": "git"
},
{
"lessThan": "635038fe19db391117e66b46bdc2b6e447ac801d",
"status": "affected",
"version": "430a049190de3c9e219f43084de9f1122da04570",
"versionType": "git"
},
{
"lessThan": "14cf0cd35361f4e94824bf8a42f72713d7702a73",
"status": "affected",
"version": "430a049190de3c9e219f43084de9f1122da04570",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/nexthop.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.3"
},
{
"lessThan": "5.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.24",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.83",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.24",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.14",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "5.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n \u003cTASK\u003e\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n ___sys_sendmsg (net/socket.c:2641)\n __sys_sendmsg (net/socket.c:2671)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \u003c/TASK\u003e\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048"
}
],
"providerMetadata": {
"dateUpdated": "2026-04-23T11:12:44.143Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/615517f3f8d53b0cf41507c7599971e17adfdfa5"
},
{
"url": "https://git.kernel.org/stable/c/40bd39e383a0478fd5c221f393df05fd9d70cfbc"
},
{
"url": "https://git.kernel.org/stable/c/635038fe19db391117e66b46bdc2b6e447ac801d"
},
{
"url": "https://git.kernel.org/stable/c/14cf0cd35361f4e94824bf8a42f72713d7702a73"
}
],
"title": "ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-31531",
"datePublished": "2026-04-23T11:12:44.143Z",
"dateReserved": "2026-03-09T15:48:24.112Z",
"dateUpdated": "2026-04-23T11:12:44.143Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-31531",
"date": "2026-04-24",
"epss": "0.0001",
"percentile": "0.0117"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2026-31531\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-04-23T12:17:01.820\",\"lastModified\":\"2026-04-23T16:17:41.280\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\\n\\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\\nallocation fails for large nexthop groups like 512 nexthops.\\n\\nThis results in the following warning splat:\\n\\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\\n [...]\\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\\n [...]\\n Call Trace:\\n \u003cTASK\u003e\\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\\n ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\\n ___sys_sendmsg (net/socket.c:2641)\\n __sys_sendmsg (net/socket.c:2671)\\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\\n \u003c/TASK\u003e\\n\\nFix this by allocating the size dynamically using nh_nlmsg_size() and\\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\\nbased on flags passed. While at it, also add the size of NHA_FDB for\\nnexthop group size calculation as it was missing too.\\n\\nThis cannot be reproduced via iproute2 as the group size is currently\\nlimited and the command fails as follows:\\n\\naddattr_l ERROR: message exceeded bound of 1048\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/14cf0cd35361f4e94824bf8a42f72713d7702a73\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/40bd39e383a0478fd5c221f393df05fd9d70cfbc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/615517f3f8d53b0cf41507c7599971e17adfdfa5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/635038fe19db391117e66b46bdc2b6e447ac801d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…