Re: [PATCH net] ipv4: validate ip_forward_options() option fields against skb tail

[Qi Tang <tpluszz77@gmail.com>]

On 5/28/26 9:48 PM, Jiayuan Chen wrote:
> The bug is real, but I'm curious what kernel version and driver you're on.
> On my side the skb falls into SKB_SMALL_HEAD_CACHE_SIZE (704), so the
> linear area is pretty long, and optptr[2] maxes out at 255, which doesn't
> look like it can reach frag_list.
>
> May the driver use alloc_skb to allocate small liner buffer?

net.git at e1914add2799 (7.1-rc3), x86_64 + KASAN, plain QEMU, no special
driver. You're right that with a normal small nh_off the +250 write stays in
the linear area. We get the reach from a large nh_off instead.

The packet is forwarded over a VXLAN-over-IPv6 tunnel, so after decap the
inner IP packet still has the outer eth/IPv6/UDP/VXLAN/inner-eth in front of
it in the same head (nh_off ~112 here). Inner options are 12 NOPs + RR, so
opt->rr = 32, and nft rewrites the RR pointer byte to 0xff on the forward
hook:

  nft add rule ip filter forward @nh,272,8 set 0xff

so ip_forward_options() does

  write = head + nh_off + opt->rr + (0xff - 5)
        = head + 112 + 32 + 250 = head + 394

with end = 384 that lands at shinfo+10, inside frag_list. ip_rt_get_source()
writes the route source there, and kfree_skb_list_reason() walks the corrupted
frag_list when the skb is dropped.

VXLAN was just convenient. Other paths likely work too: any encap that pushes
the options deeper, or a smaller head like you suggested. Pre-6.3 without
skb_small_head_cache a plain forwarded packet already has end=192. I can send
the PoC off-list if you want to repro.

Thanks,
Qi