Re: [REPORT] ipv4: nexthop: reachable WARN in rtm_get_nexthop() via oversized group dump

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 3/30/26 2:14 PM, 钱一铭 wrote:
> Hello,
> 
> I found a reachable warning in `rtm_get_nexthop()` in upstream commit
> `a989fde763f4` (`7.0.0-rc4-00029-ga989fde763f4` in my test build).
> By creating a sufficiently large IPv4 nexthop group and then issuing
> `RTM_GETNEXTHOP` for that ID, a local user can trigger
> `WARN_ON(err == -EMSGSIZE)` in `net/ipv4/nexthop.c:3393`.
> 
> With `panic_on_warn=1`, this becomes a deterministic local kernel DoS.
> Without `panic_on_warn=1`, the issue is still reachable as a user-triggerable
> kernel warning.
> 
> Source analysis
> 
> At the tested commit, `rtm_get_nexthop()` allocates a fixed-size reply skb:
> 
> - `alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL)` at `net/ipv4/nexthop.c:3381`
> 
> It then serializes the selected nexthop object into that skb:
> 
> - `nh_fill_node(...)` at `net/ipv4/nexthop.c:3390`
> 
> For group nexthops, `nh_fill_node()` emits `NHA_GROUP` and related metadata.
> If the skb is too small, the serialization helpers return `-EMSGSIZE`, and
> `nh_fill_node()` propagates that error.
> 
> The problem is that group creation-time validation does not bound the group
> size against the future `RTM_GETNEXTHOP` response size. In particular,
> `nh_check_attr_group()` validates layout, duplicate IDs, reserved fields, and
> weights, but it does not reject a group that is valid to create and later too
> large to dump back through the fixed-size `RTM_GETNEXTHOP` reply path.
> 
> The same file already has exact size estimation for nexthop dumps:
> 
> - `nh_nlmsg_size()` computes the size needed for a given nexthop object
> - `nexthop_notify()` uses `nlmsg_new(nh_nlmsg_size(nh), ...)`
> 
> So the reachable warning appears to come from a mismatch between:
> 
> 1. object creation, which accepts very large groups, and
> 2. object query through `rtm_get_nexthop()`, which still uses a fixed
>     `NLMSG_GOODSIZE` buffer.
> 
> Why 512 members are enough
> 
> `struct nexthop_grp` is 8 bytes. A 512-member group therefore needs a
> 4096-byte `NHA_GROUP` payload alone, before netlink attribute headers,
> alignment, `NHA_ID`, `NHA_GROUP_TYPE`, `NHA_OP_FLAGS`, and the `nhmsg`
> header are added. In practice, 256-member and 384-member groups were dumped
> successfully in my setup, while the first 512-member query reproducibly hit
> the warning.
> 

Hi, thanks for the report. This issue is legit, I reproduced it locally 
too. IMO, that warning and also the ones at nexthop_notify() and 
rtm_get_nexthop_bucket() should be converted to the DEBUG_NET_ variant.

Using nh_nlmsg_size() seems like the right fix but the allocation of skb 
would need to wait until nh fetched. I also wonder if we should use 
nlmsg_new() directly. Would look deeper into it.

In addition I am writing a selftest patch for this.

Thanks,
Fernando.