---
id: CVE-2026-31531
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 N…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 430a049190de3c9e219f43084de9f1122da04570 <
    18a4543c1750f96be63e349936d2dfdcb360b2dc
  - >-
    Linux >= 430a049190de3c9e219f43084de9f1122da04570 <
    615517f3f8d53b0cf41507c7599971e17adfdfa5
  - >-
    Linux >= 430a049190de3c9e219f43084de9f1122da04570 <
    40bd39e383a0478fd5c221f393df05fd9d70cfbc
  - >-
    Linux >= 430a049190de3c9e219f43084de9f1122da04570 <
    635038fe19db391117e66b46bdc2b6e447ac801d
  - >-
    Linux >= 430a049190de3c9e219f43084de9f1122da04570 <
    14cf0cd35361f4e94824bf8a42f72713d7702a73
  - Linux 5.3
published: '2026-04-23'
updated: '2026-10-21'
sourceUpdated: '2026-10-21T12:39:26.586Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-31531'
references:
  - url: 'https://git.kernel.org/stable/c/18a4543c1750f96be63e349936d2dfdcb360b2dc'
  - 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'
tags:
  - cve.org
epss: 0.00164
epssPercentile: 0.05299
ingestedAt: '2026-10-21T12:48:53.664Z'
---

## Overview

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

## Affected

- `Linux >= 430a049190de3c9e219f43084de9f1122da04570 < 18a4543c1750f96be63e349936d2dfdcb360b2dc`
- `Linux >= 430a049190de3c9e219f43084de9f1122da04570 < 615517f3f8d53b0cf41507c7599971e17adfdfa5`
- `Linux >= 430a049190de3c9e219f43084de9f1122da04570 < 40bd39e383a0478fd5c221f393df05fd9d70cfbc`
- `Linux >= 430a049190de3c9e219f43084de9f1122da04570 < 635038fe19db391117e66b46bdc2b6e447ac801d`
- `Linux >= 430a049190de3c9e219f43084de9f1122da04570 < 14cf0cd35361f4e94824bf8a42f72713d7702a73`
- `Linux 5.3`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.