Re: [PATCH net 1/5] ipv6: restrict gc_elasticity to 31

[Fernando Fernandez Mancera]

On 10/23/26 11:13 AM, Jiayuan Chen wrote:
> Every counted IPv6 dst allocation runs ip6_dst_gc() once the number of
> live dst goes over gc_thresh (1024 by default). ip6_dst_gc() decays
> ip6_rt_gc_expire by gc_elasticity: the smaller gc_elasticity is, the
> smaller ip6_rt_gc_expire gets, i.e. the more aggressive the gc.
>
> ip6_rt_gc_expire is a u32, but gc_elasticity has no upper bound, so
> writing >= 32 shifts a 32-bit value by >= 32 bits, which is UB:
>
> 	val = atomic_read(&net->ipv6.ip6_rt_gc_expire);
> 	atomic_set(&net->ipv6.ip6_rt_gc_expire, val - (val >> rt_elasticity));
>
>    UBSAN: shift-out-of-bounds in net/ipv6/route.c:3369:53
>    shift exponent 32 is too large for 32-bit type 'unsigned int'
>    CPU: 2 UID: 0 PID: 615 Comm: ping6 Not tainted 7.3.0-rc7+ #364 PREEMPT
>    Call Trace:
>     <IRQ>
>     dump_stack_lvl+0xc1/0xf0
>     dump_stack+0x10/0x20
>     __ubsan_handle_shift_out_of_bounds+0x1d1/0x390
>     ip6_dst_gc.cold+0x15/0x1a
>     dst_alloc+0x4e0/0x620
>     ip6_rt_cache_alloc+0x189/0x7e0
>     __ip6_rt_update_pmtu+0x68e/0x1160
>     ip6_update_pmtu+0x30c/0x3a0
>     icmpv6_err+0x1fa/0x330
>     icmpv6_notify+0x303/0x770
>     icmpv6_rcv+0xc12/0x1670
>     ip6_protocol_deliver_rcu+0xb4a/0x1520
>     ip6_input_finish+0x19c/0x400
>     ip6_input+0xd4/0x240
>     ipv6_rcv+0x1fd/0x330
>     __netif_receive_skb_one_core+0x118/0x1c0
>     __netif_receive_skb+0x21/0x150
>     process_backlog+0x37e/0x1200
>     __napi_poll.constprop.0+0xa5/0x5e0
>     net_rx_action+0x4c0/0xf70
>     handle_softirqs+0x204/0x9b0
>     __do_softirq+0x10/0x18
>
> Cap it at 31. 31 and 32 are equivalent anyway: ip6_rt_gc_expire starts
> at 30*HZ (~30000 with HZ=1000), and such a value shifted right by 15 or
> more is already 0, so val - (val >> rt_elasticity) stops decaying well
> before 31. Values above 31 add no new behaviour, they only hit the UB.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>

Reviewed-by: Fernando Fernandez Mancera <fmancera@xxxxxxx>

Thanks!