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

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

[Jiayuan Chen]

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@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv6/route.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 94e5ef1c4f83..6f2efc219f39 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -6579,6 +6579,8 @@ static int ipv6_sysctl_rtcache_flush(const struct ctl_table *ctl, int write,
 	return 0;
 }
 
+static int ip6_rt_gc_elasticity_max = 31;
+
 static const struct ctl_table ipv6_route_table_template[] = {
 	{
 		.procname	=	"max_size",
@@ -6627,7 +6629,9 @@ static const struct ctl_table ipv6_route_table_template[] = {
 		.data		=	&init_net.ipv6.sysctl.ip6_rt_gc_elasticity,
 		.maxlen		=	sizeof(int),
 		.mode		=	0644,
-		.proc_handler	=	proc_dointvec,
+		.proc_handler	=	proc_dointvec_minmax,
+		.extra1		=	SYSCTL_ZERO,
+		.extra2		=	&ip6_rt_gc_elasticity_max,
 	},
 	{
 		.procname	=	"mtu_expires",
-- 
2.43.0

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@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>

Thanks!

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

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message for "ipv6: restrict gc_elasticity to 31" says
  only "Cap it at 31", and its reasoning covers only values >= 32.

--

ipv6: restrict gc_elasticity to 31

This commit switches the net.ipv6.route.gc_elasticity sysctl from
proc_dointvec to proc_dointvec_minmax with bounds [0, 31]. The upper bound
avoids an out-of-bounds shift of the u32 ip6_rt_gc_expire in ip6_dst_gc()
that UBSAN reported.

> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 94e5ef1c4f83e..6f2efc219f395 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c

[ ... ]

> @@ -6627,7 +6629,9 @@ static const struct ctl_table ipv6_route_table_template[] = {
>  		.data		=	&init_net.ipv6.sysctl.ip6_rt_gc_elasticity,
>  		.maxlen		=	sizeof(int),
>  		.mode		=	0644,
> -		.proc_handler	=	proc_dointvec,
> +		.proc_handler	=	proc_dointvec_minmax,
> +		.extra1		=	SYSCTL_ZERO,

[Severity: Low]
This isn't a bug, but should the commit message mention the new lower
bound too?

The changelog says:

  Cap it at 31. 31 and 32 are equivalent anyway [ ... ]
  Values above 31 add no new behaviour, they only hit the UB.

This only covers values >= 32. With extra1 set to SYSCTL_ZERO, negative
writes that proc_dointvec used to accept will now fail as well.

The lower bound also fixes real UB. In ip6_dst_gc(), rt_elasticity is a
signed int read from the sysctl:

	int rt_elasticity = READ_ONCE(net->ipv6.sysctl.ip6_rt_gc_elasticity);
	[ ... ]
	atomic_set(&net->ipv6.ip6_rt_gc_expire, val - (val >> rt_elasticity));

so a negative value also gives a negative shift count.

"Cap" also reads as if values get clamped. proc_dointvec_minmax actually
rejects writes outside [0, 31] with -EINVAL.

Since this is tagged for stable, could the changelog say that writes
outside [0, 31] are now rejected in both directions? That would help
anyone with a negative or >= 32 value in sysctl.conf who starts seeing
the write fail.

> +		.extra2		=	&ip6_rt_gc_elasticity_max,
>  	},
>  	{
>  		.procname	=	"mtu_expires",

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261023091419.167088-1-jiayuan.chen%40linux.dev

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

[Kuniyuki Iwashima]

On Fri, 23 Oct 2026 17:13:27 +0800, 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@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  net/ipv6/route.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 94e5ef1c4f83..6f2efc219f39 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -6579,6 +6579,8 @@ static int ipv6_sysctl_rtcache_flush(const struct ctl_table *ctl, int write,
>  	return 0;
>  }
>  
> +static int ip6_rt_gc_elasticity_max = 31;
> +
>  static const struct ctl_table ipv6_route_table_template[] = {
>  	{
>  		.procname	=	"max_size",
> @@ -6627,7 +6629,9 @@ static const struct ctl_table ipv6_route_table_template[] = {
>  		.data		=	&init_net.ipv6.sysctl.ip6_rt_gc_elasticity,
>  		.maxlen		=	sizeof(int),
>  		.mode		=	0644,
> -		.proc_handler	=	proc_dointvec,
> +		.proc_handler	=	proc_dointvec_minmax,

If you need v2 or as follow-up in net-next, please make it u8.

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>




> +		.extra1		=	SYSCTL_ZERO,
> +		.extra2		=	&ip6_rt_gc_elasticity_max,
>  	},
>  	{
>  		.procname	=	"mtu_expires",
> -- 
> 2.43.0
> 

[PATCH net 2/5] ipv4: fix shift-out-of-bounds in ip_rt_send_redirect()

[Jiayuan Chen]

ip_rt_redirect_number is the max number of ICMP Redirects we send to one
endpoint; once we hit it we stop. Before that, ip_rt_redirect_load gives
the redirects an exponential backoff:

	if (peer->n_redirects == 0 ||
	    time_after(jiffies,
		       (peer->rate_last +
			(ip_rt_redirect_load << peer->n_redirects)))) {

n_redirects only stops growing when it reaches ip_rt_redirect_number, and
both redirect_number and redirect_load are plain proc_dointvec sysctls
with no upper bound. Set redirect_number past 32 and n_redirects climbs
past 31, so "ip_rt_redirect_load << peer->n_redirects" shifts a 32-bit
int by >= 32 bits, which is UB:

  UBSAN: shift-out-of-bounds in net/ipv4/route.c:949:6
  shift exponent 32 is too large for 32-bit type 'int'
  CPU: 1 UID: 0 PID: 1845 Comm: ping 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
   ip_rt_send_redirect.cold+0x2c/0x146
   ip_forward+0x1ddc/0x2430
   ip_rcv+0x2b1/0x320
   __netif_receive_skb_one_core+0x16b/0x1c0
   __netif_receive_skb+0x21/0x150
   process_backlog+0x37e/0x1200
   __napi_poll.constprop.0+0xa5/0x5e0
   net_rx_action+0x4c0/0xf70

Fixing this from the sysctl side would mean bounding both knobs, e.g.
redirect_load to [0, 65535] and redirect_number to [0, 16], which gets
in the way of users who legitimately do not want to cap ICMP redirects.
Instead compute the backoff in u64 with the shift count capped at 31,
which cannot overflow since ip_rt_redirect_load is an int, and clamp the
result to MAX_JIFFY_OFFSET.

The clamp also fixes 32-bit kernels, where the same expression goes
wrong long before the shift count reaches 32. With the default
ip_rt_redirect_load of 20, from n_redirects == 27 on the result is
either truncated or too large for time_after(), which then treats the
deadline as already passed, and from 30 on it is 0, so every forwarded
packet gets a redirect again until ip_rt_redirect_number is reached.
This needs a raised redirect_silence to be reachable, otherwise
n_redirects is reset long before. On 64-bit, ip_rt_redirect_load << 31
stays below MAX_JIFFY_OFFSET, so nothing changes there.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv4/route.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 595a3b7f1783..76807b757046 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -907,6 +907,7 @@ void ip_rt_send_redirect(struct sk_buff *skb)
 	struct inet_peer *peer;
 	int log_martians;
 	struct net *net;
+	u64 backoff;
 	int vif;
 
 	rcu_read_lock();
@@ -945,10 +946,10 @@ void ip_rt_send_redirect(struct sk_buff *skb)
 	/* Check for load limit; set rate_last to the latest sent
 	 * redirect.
 	 */
+	backoff = (u64)ip_rt_redirect_load << min(peer->n_redirects, 31U);
+	backoff = min_t(u64, backoff, MAX_JIFFY_OFFSET);
 	if (peer->n_redirects == 0 ||
-	    time_after(jiffies,
-		       (peer->rate_last +
-			(ip_rt_redirect_load << peer->n_redirects)))) {
+	    time_after(jiffies, peer->rate_last + (unsigned long)backoff)) {
 		__be32 gw = rt_nexthop(rt, ip_hdr(skb)->daddr);
 
 		icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);
-- 
2.43.0

Re: [PATCH net 2/5] ipv4: fix shift-out-of-bounds in ip_rt_send_redirect()

[Fernando Fernandez Mancera]

On 10/23/26 11:13 AM, Jiayuan Chen wrote:
> ip_rt_redirect_number is the max number of ICMP Redirects we send to one
> endpoint; once we hit it we stop. Before that, ip_rt_redirect_load gives
> the redirects an exponential backoff:
> 
> 	if (peer->n_redirects == 0 ||
> 	    time_after(jiffies,
> 		       (peer->rate_last +
> 			(ip_rt_redirect_load << peer->n_redirects)))) {
> 
> n_redirects only stops growing when it reaches ip_rt_redirect_number, and
> both redirect_number and redirect_load are plain proc_dointvec sysctls
> with no upper bound. Set redirect_number past 32 and n_redirects climbs
> past 31, so "ip_rt_redirect_load << peer->n_redirects" shifts a 32-bit
> int by >= 32 bits, which is UB:
> 
>    UBSAN: shift-out-of-bounds in net/ipv4/route.c:949:6
>    shift exponent 32 is too large for 32-bit type 'int'
>    CPU: 1 UID: 0 PID: 1845 Comm: ping 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
>     ip_rt_send_redirect.cold+0x2c/0x146
>     ip_forward+0x1ddc/0x2430
>     ip_rcv+0x2b1/0x320
>     __netif_receive_skb_one_core+0x16b/0x1c0
>     __netif_receive_skb+0x21/0x150
>     process_backlog+0x37e/0x1200
>     __napi_poll.constprop.0+0xa5/0x5e0
>     net_rx_action+0x4c0/0xf70
> 
> Fixing this from the sysctl side would mean bounding both knobs, e.g.
> redirect_load to [0, 65535] and redirect_number to [0, 16], which gets
> in the way of users who legitimately do not want to cap ICMP redirects.
> Instead compute the backoff in u64 with the shift count capped at 31,
> which cannot overflow since ip_rt_redirect_load is an int, and clamp the
> result to MAX_JIFFY_OFFSET.
> 

I think we should cap redirect_load with a minimum valid value of 0 on 
the sysctl. If the user want to disable ICMP redirects or do not cap 
them, they should use 0 or -1 in redirect_number IMHO.

What do you think?

> The clamp also fixes 32-bit kernels, where the same expression goes
> wrong long before the shift count reaches 32. With the default
> ip_rt_redirect_load of 20, from n_redirects == 27 on the result is
> either truncated or too large for time_after(), which then treats the
> deadline as already passed, and from 30 on it is 0, so every forwarded
> packet gets a redirect again until ip_rt_redirect_number is reached.
> This needs a raised redirect_silence to be reachable, otherwise
> n_redirects is reset long before. On 64-bit, ip_rt_redirect_load << 31
> stays below MAX_JIFFY_OFFSET, so nothing changes there.
> 

Isn't the same issue in 64-bit kernels too? In essence, it would be (int 
<< u32) which results in a negative value and that is later 
sign-extended to a corrupted 64-bit value. Am I missing something here?

> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>   net/ipv4/route.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 595a3b7f1783..76807b757046 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -907,6 +907,7 @@ void ip_rt_send_redirect(struct sk_buff *skb)
>   	struct inet_peer *peer;
>   	int log_martians;
>   	struct net *net;
> +	u64 backoff;
>   	int vif;
>   
>   	rcu_read_lock();
> @@ -945,10 +946,10 @@ void ip_rt_send_redirect(struct sk_buff *skb)
>   	/* Check for load limit; set rate_last to the latest sent
>   	 * redirect.
>   	 */
> +	backoff = (u64)ip_rt_redirect_load << min(peer->n_redirects, 31U);
> +	backoff = min_t(u64, backoff, MAX_JIFFY_OFFSET);
>   	if (peer->n_redirects == 0 ||
> -	    time_after(jiffies,
> -		       (peer->rate_last +
> -			(ip_rt_redirect_load << peer->n_redirects)))) {
> +	    time_after(jiffies, peer->rate_last + (unsigned long)backoff)) {
>   		__be32 gw = rt_nexthop(rt, ip_hdr(skb)->daddr);
>   
>   		icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);

Re: [PATCH net 2/5] ipv4: fix shift-out-of-bounds in ip_rt_send_redirect()

[Jiayuan Chen]

On 10/23/26 10:11 PM, Fernando Fernandez Mancera wrote:
> On 10/23/26 11:13 AM, Jiayuan Chen wrote:
>> ip_rt_redirect_number is the max number of ICMP Redirects we send to one
>> endpoint; once we hit it we stop. Before that, ip_rt_redirect_load gives
>> the redirects an exponential backoff:
>>
>>     if (peer->n_redirects == 0 ||
>>         time_after(jiffies,
>>                (peer->rate_last +
>>             (ip_rt_redirect_load << peer->n_redirects)))) {
>>
>> n_redirects only stops growing when it reaches ip_rt_redirect_number, 
>> and
>> both redirect_number and redirect_load are plain proc_dointvec sysctls
>> with no upper bound. Set redirect_number past 32 and n_redirects climbs
>> past 31, so "ip_rt_redirect_load << peer->n_redirects" shifts a 32-bit
>> int by >= 32 bits, which is UB:
>>
>>    UBSAN: shift-out-of-bounds in net/ipv4/route.c:949:6
>>    shift exponent 32 is too large for 32-bit type 'int'
>>    CPU: 1 UID: 0 PID: 1845 Comm: ping 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
>>     ip_rt_send_redirect.cold+0x2c/0x146
>>     ip_forward+0x1ddc/0x2430
>>     ip_rcv+0x2b1/0x320
>>     __netif_receive_skb_one_core+0x16b/0x1c0
>>     __netif_receive_skb+0x21/0x150
>>     process_backlog+0x37e/0x1200
>>     __napi_poll.constprop.0+0xa5/0x5e0
>>     net_rx_action+0x4c0/0xf70
>>
>> Fixing this from the sysctl side would mean bounding both knobs, e.g.
>> redirect_load to [0, 65535] and redirect_number to [0, 16], which gets
>> in the way of users who legitimately do not want to cap ICMP redirects.
>> Instead compute the backoff in u64 with the shift count capped at 31,
>> which cannot overflow since ip_rt_redirect_load is an int, and clamp the
>> result to MAX_JIFFY_OFFSET.
>>
>
> I think we should cap redirect_load with a minimum valid value of 0 on 
> the sysctl. If the user want to disable ICMP redirects or do not cap 
> them, they should use 0 or -1 in redirect_number IMHO.
>
> What do you think?
>
>> The clamp also fixes 32-bit kernels, where the same expression goes
>> wrong long before the shift count reaches 32. With the default
>> ip_rt_redirect_load of 20, from n_redirects == 27 on the result is
>> either truncated or too large for time_after(), which then treats the
>> deadline as already passed, and from 30 on it is 0, so every forwarded
>> packet gets a redirect again until ip_rt_redirect_number is reached.
>> This needs a raised redirect_silence to be reachable, otherwise
>> n_redirects is reset long before. On 64-bit, ip_rt_redirect_load << 31
>> stays below MAX_JIFFY_OFFSET, so nothing changes there.
>>
>
> Isn't the same issue in 64-bit kernels too? In essence, it would be 
> (int << u32) which results in a negative value and that is later 
> sign-extended to a corrupted 64-bit value. Am I missing something here?
>

Thanks for pointing this out, agreed. A negative redirect_load never
meant anything: with the old int shift it just made the deadline land in
the past, i.e. no backoff at all, which is exactly what 0 gives. And once
converted to u64 it would turn into the maximum backoff instead, so it
should be rejected rather than silently mapped to something.

Re: [PATCH net 2/5] ipv4: fix shift-out-of-bounds in ip_rt_send_redirect()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new backoff code in ip_rt_send_redirect() casts the signed
  sysctl `ip_rt_redirect_load` straight to u64.

--

ipv4: fix shift-out-of-bounds in ip_rt_send_redirect()

This commit fixes a UBSAN shift-out-of-bounds in ip_rt_send_redirect().
The shift happens when ip_rt_redirect_number is set above 32. The backoff
is now computed in u64 with the shift count capped at 31, and the result
is clamped to MAX_JIFFY_OFFSET before it is passed to time_after().

> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 595a3b7f17830..76807b7570467 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c

[ ... ]

> @@ -945,10 +946,10 @@ void ip_rt_send_redirect(struct sk_buff *skb)
>  	/* Check for load limit; set rate_last to the latest sent
>  	 * redirect.
>  	 */
> +	backoff = (u64)ip_rt_redirect_load << min(peer->n_redirects, 31U);
> +	backoff = min_t(u64, backoff, MAX_JIFFY_OFFSET);

[Severity: Medium]
What happens here when ip_rt_redirect_load is negative?

The redirect_load sysctl is a plain proc_dointvec with no extra1/extra2
bounds, so root can write a negative value:

net/ipv4/route.c:ipv4_route_table[] {
    ...
	.procname	= "redirect_load",
	.data		= &ip_rt_redirect_load,
	.maxlen		= sizeof(int),
	.mode		= 0644,
	.proc_handler	= proc_dointvec,
    ...
}

When the load is a negative x, (u64)ip_rt_redirect_load sign-extends to
2^64 + x. For any shift n <= 31, the shifted value mod 2^64 is
2^64 + x * 2^n, which is still at or above 2^63.

The min_t() would then always return MAX_JIFFY_OFFSET, and this check
would effectively never be true:

    time_after(jiffies, peer->rate_last + MAX_JIFFY_OFFSET)

So after the first redirect (n_redirects == 0 skips the check), does a
peer get no more redirects until the ip_rt_redirect_silence reset clears
n_redirects?

Before this patch, a negative load produced a negative offset from
rate_last. time_after() was then always true, so a redirect went out on
every packet until ip_rt_redirect_number was reached. With this patch a
negative redirect_load seems to change from no backoff to maximum backoff.

The commit message says the u64 computation "cannot overflow since
ip_rt_redirect_load is an int". That only seems to hold for non-negative
values.

A later patch in this series restricts message_cost and message_burst to
non-negative values. It doesn't touch redirect_load, and route.c is
unchanged through the end of the series.

Would it make sense to treat a negative load as 0 before the cast? The
other option is a lower bound on the sysctl, for example
proc_dointvec_minmax with extra1 = SYSCTL_ZERO.

>  	if (peer->n_redirects == 0 ||
> -	    time_after(jiffies,
> -		       (peer->rate_last +
> -			(ip_rt_redirect_load << peer->n_redirects)))) {
> +	    time_after(jiffies, peer->rate_last + (unsigned long)backoff)) {
>  		__be32 gw = rt_nexthop(rt, ip_hdr(skb)->daddr);
>  
>  		icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261023091419.167088-1-jiayuan.chen%40linux.dev

[PATCH net 3/5] ipv6: restrict mld_qrv to 255

[Jiayuan Chen]

net.ipv6.mld_qrv only has a lower bound, but ipv6_mc_reset() stores it
into the u8 inet6_dev::mc_qrv, and every MLD retransmit counter derived
from it (mca_crcount, sf_crcount, mc_ifc_count, mc_dad_count) is u8 as
well. Anything above 255 silently wraps: 256 becomes 0, so no state
change report is ever retransmitted, and the first MLDv2 Query received
on the interface then trips the WARN_ON() in mld_update_qrv():

	WARN_ON(idev->mc_qrv == 0);

A plain bridge with mcast_querier enabled on the link is enough:

  WARNING: net/ipv6/mcast.c:1327 at mld_query_work+0x1fd2/0x2cb0, CPU#3: kworker/3:1/2688
  Workqueue: mld mld_query_work
  RIP: 0010:mld_query_work+0x1fd2/0x2cb0
  Call Trace:
   <TASK>
   process_one_work+0x93a/0x1b20
   worker_thread+0x6d0/0x11d0
   kthread+0x358/0x470
   ret_from_fork+0x5b3/0x820
   ret_from_fork_asm+0x1a/0x30
   </TASK>

Cap the sysctl at U8_MAX, the largest value mc_qrv can actually hold.

Fixes: 2f711939d2ea ("ipv6: add sysctl_mld_qrv to configure query robustness variable")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv6/sysctl_net_ipv6.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 1a0a36dcdabc..05a384680332 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -29,6 +29,7 @@ static u32 rt6_multipath_hash_fields_all_mask =
 	FIB_MULTIPATH_HASH_FIELD_ALL_MASK;
 static u32 ioam6_id_max = IOAM6_DEFAULT_ID;
 static u64 ioam6_id_wide_max = IOAM6_DEFAULT_ID_WIDE;
+static int mld_qrv_max = U8_MAX;
 
 static int proc_rt6_multipath_hash_policy(const struct ctl_table *table, int write,
 					  void *buffer, size_t *lenp, loff_t *ppos)
@@ -229,7 +230,8 @@ static struct ctl_table ipv6_rotable[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec_minmax,
-		.extra1		= SYSCTL_ONE
+		.extra1		= SYSCTL_ONE,
+		.extra2		= &mld_qrv_max,
 	},
 #ifdef CONFIG_NETLABEL
 	{
-- 
2.43.0

Re: [PATCH net 3/5] ipv6: restrict mld_qrv to 255

[Fernando Fernandez Mancera]

On 10/23/26 11:13 AM, Jiayuan Chen wrote:
> net.ipv6.mld_qrv only has a lower bound, but ipv6_mc_reset() stores it
> into the u8 inet6_dev::mc_qrv, and every MLD retransmit counter derived
> from it (mca_crcount, sf_crcount, mc_ifc_count, mc_dad_count) is u8 as
> well. Anything above 255 silently wraps: 256 becomes 0, so no state
> change report is ever retransmitted, and the first MLDv2 Query received
> on the interface then trips the WARN_ON() in mld_update_qrv():
> 
> 	WARN_ON(idev->mc_qrv == 0);
> 
> A plain bridge with mcast_querier enabled on the link is enough:
> 
>    WARNING: net/ipv6/mcast.c:1327 at mld_query_work+0x1fd2/0x2cb0, CPU#3: kworker/3:1/2688
>    Workqueue: mld mld_query_work
>    RIP: 0010:mld_query_work+0x1fd2/0x2cb0
>    Call Trace:
>     <TASK>
>     process_one_work+0x93a/0x1b20
>     worker_thread+0x6d0/0x11d0
>     kthread+0x358/0x470
>     ret_from_fork+0x5b3/0x820
>     ret_from_fork_asm+0x1a/0x30
>     </TASK>
> 
> Cap the sysctl at U8_MAX, the largest value mc_qrv can actually hold.
> 
> Fixes: 2f711939d2ea ("ipv6: add sysctl_mld_qrv to configure query robustness variable")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>

Thanks!

Re: [PATCH net 3/5] ipv6: restrict mld_qrv to 255

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] This patch adds an upper bound to net.ipv6.mld_qrv in
  net/ipv6/sysctl_net_ipv6.c: `static int mld_qrv_max = U8_MAX;` at line…

--

ipv6: restrict mld_qrv to 255

This commit adds an upper bound of U8_MAX to the net.ipv6.mld_qrv
sysctl. ipv6_mc_reset() stores the value in the u8 inet6_dev::mc_qrv, so
larger values wrap. A value of 256 wraps to 0, which then trips the
WARN_ON() in mld_update_qrv() when an MLDv2 query arrives.

> diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
> index 1a0a36dcdabc1..05a3846803322 100644
> --- a/net/ipv6/sysctl_net_ipv6.c
> +++ b/net/ipv6/sysctl_net_ipv6.c

[ ... ]

> @@ -229,7 +230,8 @@ static struct ctl_table ipv6_rotable[] = {
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
>  		.proc_handler	= proc_dointvec_minmax,
> -		.extra1		= SYSCTL_ONE
> +		.extra1		= SYSCTL_ONE,
> +		.extra2		= &mld_qrv_max,
>  	},

[Severity: Low]
This isn't a bug, but should Documentation/networking/ip-sysctl.rst be
updated to match? The mld_qrv entry there already lists its lower limit,
but it doesn't mention the new maximum:

mld_qrv - INTEGER
	Controls the MLD query robustness variable (see RFC3810 9.1).

	Default: 2 (as specified by RFC3810 9.1)

	Minimum: 1 (as specified by RFC6636 4.5)

With extra2 set to &mld_qrv_max, proc_dointvec_minmax() now rejects
writes above 255 with -EINVAL. Writes such as 256 or 1000 used to be
accepted.

Could a "Maximum: 255" line be added, maybe with a short note that the
value is stored in a u8?

No later patch in the series seems to update this file. The igmp_qrv
entry in ip-sysctl.rst also still lists only a minimum, even though
igmp_qrv also appears to be capped at 255 by the end of the series.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261023091419.167088-1-jiayuan.chen%40linux.dev

Re: [PATCH net 3/5] ipv6: restrict mld_qrv to 255

[Kuniyuki Iwashima]

On Fri, 23 Oct 2026 17:13:29 +0800, Jiayuan Chen wrote:
> net.ipv6.mld_qrv only has a lower bound, but ipv6_mc_reset() stores it
> into the u8 inet6_dev::mc_qrv, and every MLD retransmit counter derived
> from it (mca_crcount, sf_crcount, mc_ifc_count, mc_dad_count) is u8 as
> well. Anything above 255 silently wraps: 256 becomes 0, so no state
> change report is ever retransmitted, and the first MLDv2 Query received
> on the interface then trips the WARN_ON() in mld_update_qrv():
> 
> 	WARN_ON(idev->mc_qrv == 0);
> 
> A plain bridge with mcast_querier enabled on the link is enough:
> 
>   WARNING: net/ipv6/mcast.c:1327 at mld_query_work+0x1fd2/0x2cb0, CPU#3: kworker/3:1/2688
>   Workqueue: mld mld_query_work
>   RIP: 0010:mld_query_work+0x1fd2/0x2cb0
>   Call Trace:
>    <TASK>
>    process_one_work+0x93a/0x1b20
>    worker_thread+0x6d0/0x11d0
>    kthread+0x358/0x470
>    ret_from_fork+0x5b3/0x820
>    ret_from_fork_asm+0x1a/0x30
>    </TASK>
> 
> Cap the sysctl at U8_MAX, the largest value mc_qrv can actually hold.
> 
> Fixes: 2f711939d2ea ("ipv6: add sysctl_mld_qrv to configure query robustness variable")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  net/ipv6/sysctl_net_ipv6.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
> index 1a0a36dcdabc..05a384680332 100644
> --- a/net/ipv6/sysctl_net_ipv6.c
> +++ b/net/ipv6/sysctl_net_ipv6.c
> @@ -29,6 +29,7 @@ static u32 rt6_multipath_hash_fields_all_mask =
>  	FIB_MULTIPATH_HASH_FIELD_ALL_MASK;
>  static u32 ioam6_id_max = IOAM6_DEFAULT_ID;
>  static u64 ioam6_id_wide_max = IOAM6_DEFAULT_ID_WIDE;
> +static int mld_qrv_max = U8_MAX;
>  
>  static int proc_rt6_multipath_hash_policy(const struct ctl_table *table, int write,
>  					  void *buffer, size_t *lenp, loff_t *ppos)
> @@ -229,7 +230,8 @@ static struct ctl_table ipv6_rotable[] = {
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
>  		.proc_handler	= proc_dointvec_minmax,

inet6_dev.mc_qrv is u8, you can simply use proc_dou8vec_minmax()
instead of adding extra2.


> -		.extra1		= SYSCTL_ONE
> +		.extra1		= SYSCTL_ONE,
> +		.extra2		= &mld_qrv_max,
>  	},
>  #ifdef CONFIG_NETLABEL
>  	{
> -- 
> 2.43.0
> 

[PATCH net 4/5] ipv4: restrict igmp_qrv to 255

[Jiayuan Chen]

net.ipv4.igmp_qrv only has a lower bound, but ip_mc_reset() stores it
into the u8 in_device::mr_qrv, and the IGMPv3 retransmit counters filled
from it (crcount, sf_crcount) are u8 as well. Anything above 255
silently wraps. With 256, mr_qrv becomes 0, every
"in_dev->mr_qrv ?: sysctl_igmp_qrv" falls back to 256, which truncates
to 0 again in crcount, and igmpv3_send_cr() never puts the state change
records for the group into a report. The older version querier present
timeout (mr_qrv * mr_qi + mr_qri) also collapses to just mr_qri.

Unlike MLD there is no WARN_ON() here, the reports just go missing.

Cap the sysctl at U8_MAX, the largest value mr_qrv can actually hold.

Fixes: a9fe8e29945d ("ipv4: implement igmp_qrv sysctl to tune igmp robustness variable")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv4/sysctl_net_ipv4.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index e3760daa3470..ef631a2759b0 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -33,6 +33,7 @@ static int ip_privileged_port_min;
 static int ip_privileged_port_max = 65535;
 static int ip_ttl_min = 1;
 static int ip_ttl_max = 255;
+static int igmp_qrv_max __maybe_unused = U8_MAX;
 static int tcp_syn_retries_min = 1;
 static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
 static int tcp_syn_linear_timeouts_max = MAX_TCP_SYNCNT;
@@ -978,7 +979,8 @@ static const struct ctl_table ipv4_net_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec_minmax,
-		.extra1		= SYSCTL_ONE
+		.extra1		= SYSCTL_ONE,
+		.extra2		= &igmp_qrv_max,
 	},
 #endif
 	{
-- 
2.43.0

Re: [PATCH net 4/5] ipv4: restrict igmp_qrv to 255

[Fernando Fernandez Mancera]

On 10/23/26 11:13 AM, Jiayuan Chen wrote:
> net.ipv4.igmp_qrv only has a lower bound, but ip_mc_reset() stores it
> into the u8 in_device::mr_qrv, and the IGMPv3 retransmit counters filled
> from it (crcount, sf_crcount) are u8 as well. Anything above 255
> silently wraps. With 256, mr_qrv becomes 0, every
> "in_dev->mr_qrv ?: sysctl_igmp_qrv" falls back to 256, which truncates
> to 0 again in crcount, and igmpv3_send_cr() never puts the state change
> records for the group into a report. The older version querier present
> timeout (mr_qrv * mr_qi + mr_qri) also collapses to just mr_qri.
> 
> Unlike MLD there is no WARN_ON() here, the reports just go missing.
> 
> Cap the sysctl at U8_MAX, the largest value mr_qrv can actually hold.
> 
> Fixes: a9fe8e29945d ("ipv4: implement igmp_qrv sysctl to tune igmp robustness variable")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>

Thanks!

Re: [PATCH net 4/5] ipv4: restrict igmp_qrv to 255

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] This patch adds an upper bound to net.ipv4.igmp_qrv.

Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but even with
  the new cap igmp_qrv still accepts 1..255.

--

ipv4: restrict igmp_qrv to 255

This commit caps net.ipv4.igmp_qrv at U8_MAX. Without the cap, the value
is truncated when it is stored into the u8 in_device::mr_qrv and the u8
crcount/sf_crcount counters. With a value of 256, IGMPv3 state change
records are never sent.

> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index e3760daa34706..ef631a2759b03 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c

[ ... ]

> @@ -978,7 +979,8 @@ static const struct ctl_table ipv4_net_table[] = {
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
>  		.proc_handler	= proc_dointvec_minmax,
> -		.extra1		= SYSCTL_ONE
> +		.extra1		= SYSCTL_ONE,
> +		.extra2		= &igmp_qrv_max,

[Severity: Low]
Should Documentation/networking/ip-sysctl.rst be updated as well? With
this patch, a write of 256 or more to net.ipv4.igmp_qrv fails with
-EINVAL, but the igmp_qrv entry still lists only a default and a minimum:

igmp_qrv - INTEGER
	Controls the IGMP query robustness variable (see RFC2236 8.1).

	Default: 2 (as specified by RFC2236 8.1)

	Minimum: 1 (as specified by RFC6636 4.5)

Could a "Maximum: 255" line be added here?

The companion patch "ipv6: restrict mld_qrv to 255" leaves the mld_qrv
entry in the same state.

[Severity: Medium]
This isn't a bug introduced by this patch, but the new cap still allows
values from 8 to 255. Is that enough for the AMT relay?

drivers/net/amt.c writes the sysctl straight into the 3-bit QRV field of
struct igmpv3_query (qrv:3 in include/uapi/linux/igmp.h):

drivers/net/amt.c:amt_build_igmp_gq() {
    ...
	ihv3->qrv	= READ_ONCE(amt->net->ipv4.sysctl_igmp_qrv);
    ...
}

In relay mode, amt_newlink() also copies the same sysctl into amt->qrv:

	if (amt->mode == AMT_MODE_RELAY) {
		amt->qrv = READ_ONCE(amt->net->ipv4.sysctl_igmp_qrv);

amt_build_mld_gq() then writes amt->qrv into the 3-bit MLDv2 field:

	mld2q->mld2q_qrv	= amt->qrv;

Neither path clamps the value or applies the RFC 3376 4.1.6 rule, which
says a robustness variable above 7 is sent as QRV=0.

So with igmp_qrv set to 9 or 10, does the relay send QRV=1 or QRV=2 on
the wire? If so, hosts that follow the querier's QRV would use a lower
robustness value than the one configured.

A fix for this would probably belong in amt.c rather than in the sysctl
bound.

>  	},
>  #endif
>  	{

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261023091419.167088-1-jiayuan.chen%40linux.dev

Re: [PATCH net 4/5] ipv4: restrict igmp_qrv to 255

[Kuniyuki Iwashima]

On Fri, 23 Oct 2026 17:13:30 +0800, Jiayuan Chen wrote:
> net.ipv4.igmp_qrv only has a lower bound, but ip_mc_reset() stores it
> into the u8 in_device::mr_qrv, and the IGMPv3 retransmit counters filled
> from it (crcount, sf_crcount) are u8 as well. Anything above 255
> silently wraps. With 256, mr_qrv becomes 0, every
> "in_dev->mr_qrv ?: sysctl_igmp_qrv" falls back to 256, which truncates
> to 0 again in crcount, and igmpv3_send_cr() never puts the state change
> records for the group into a report. The older version querier present
> timeout (mr_qrv * mr_qi + mr_qri) also collapses to just mr_qri.
> 
> Unlike MLD there is no WARN_ON() here, the reports just go missing.
> 
> Cap the sysctl at U8_MAX, the largest value mr_qrv can actually hold.
> 
> Fixes: a9fe8e29945d ("ipv4: implement igmp_qrv sysctl to tune igmp robustness variable")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  net/ipv4/sysctl_net_ipv4.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
> index e3760daa3470..ef631a2759b0 100644
> --- a/net/ipv4/sysctl_net_ipv4.c
> +++ b/net/ipv4/sysctl_net_ipv4.c
> @@ -33,6 +33,7 @@ static int ip_privileged_port_min;
>  static int ip_privileged_port_max = 65535;
>  static int ip_ttl_min = 1;
>  static int ip_ttl_max = 255;
> +static int igmp_qrv_max __maybe_unused = U8_MAX;
>  static int tcp_syn_retries_min = 1;
>  static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
>  static int tcp_syn_linear_timeouts_max = MAX_TCP_SYNCNT;
> @@ -978,7 +979,8 @@ static const struct ctl_table ipv4_net_table[] = {
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
>  		.proc_handler	= proc_dointvec_minmax,

Same, please use proc_dou8vec_minmax().


> -		.extra1		= SYSCTL_ONE
> +		.extra1		= SYSCTL_ONE,
> +		.extra2		= &igmp_qrv_max,
>  	},
>  #endif
>  	{
> -- 
> 2.43.0
> 

[PATCH net 5/5] net: restrict message_cost and message_burst to non-negative values

[Jiayuan Chen]

net.core.message_cost and net.core.message_burst feed the interval and
burst of net_ratelimit_state, but neither has a lower bound:
message_burst uses plain proc_dointvec, and message_cost uses
proc_dointvec_jiffies, which happily stores -1 second as -HZ jiffies.

Since commit a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are
negative"), ___ratelimit() splats on such values, so the next
net_ratelimit() caller warns, e.g. a martian source log:

  Negative interval (-250) or burst (10): Uninitialized ratelimit_state structure?
  WARNING: lib/ratelimit.c:43 at ___ratelimit+0x56e/0x960, CPU#1: ping/3218
  RIP: 0010:___ratelimit+0x578/0x960
  Call Trace:
   <IRQ>
   net_ratelimit+0x1c/0x30
   ip_handle_martian_source+0x1bb/0x340
   ip_route_input_slow+0x1057/0x3650
   ip_route_input_noref+0x104/0x260
   arp_process+0x109b/0x2510
   arp_rcv+0x381/0x460
   __netif_receive_skb_one_core+0x173/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
   do_softirq.part.0+0x49/0xd0
   </IRQ>

Negative values never meant anything here: ___ratelimit() treats them
like 0, and 0 already expresses both "no limit" (interval) and
"suppress everything" (burst).

Reject them at write time. message_burst can simply use
proc_dointvec_minmax with extra1 = 0. proc_dointvec_jiffies ignores
extra1/extra2, so give message_cost a small handler that parses into a
temporary and only stores the value if it is not negative.

Fixes: a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are negative")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/core/sysctl_net_core.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 473c162736d6..8146ed819695 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -378,6 +378,22 @@ static int proc_do_skb_defer_max(const struct ctl_table *table, int write,
 	return ret;
 }
 
+static int proc_do_message_cost(const struct ctl_table *table, int write,
+				void *buffer, size_t *lenp, loff_t *ppos)
+{
+	int ret, interval = READ_ONCE(*(int *)table->data);
+	struct ctl_table tmp = *table;
+
+	tmp.data = &interval;
+	ret = proc_dointvec_jiffies(&tmp, write, buffer, lenp, ppos);
+	if (write && !ret) {
+		if (interval < 0)
+			return -EINVAL;
+		WRITE_ONCE(*(int *)table->data, interval);
+	}
+	return ret;
+}
+
 #ifdef CONFIG_BPF_JIT
 static int proc_dointvec_minmax_bpf_enable(const struct ctl_table *table, int write,
 					   void *buffer, size_t *lenp,
@@ -544,14 +560,15 @@ static struct ctl_table net_core_table[] = {
 		.data		= &net_ratelimit_state.interval,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec_jiffies,
+		.proc_handler	= proc_do_message_cost,
 	},
 	{
 		.procname	= "message_burst",
 		.data		= &net_ratelimit_state.burst,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= SYSCTL_ZERO,
 	},
 #ifdef CONFIG_RPS
 	{
-- 
2.43.0

Re: [PATCH net 5/5] net: restrict message_cost and message_burst to non-negative values

[Joel Granados]

[-- Attachment #1: Type: text/plain, Size: 6798 bytes --]

On Fri, Oct 23, 2026 at 05:13:31PM +0800, Jiayuan Chen wrote:
> net.core.message_cost and net.core.message_burst feed the interval and
> burst of net_ratelimit_state, but neither has a lower bound:
> message_burst uses plain proc_dointvec, and message_cost uses
> proc_dointvec_jiffies, which happily stores -1 second as -HZ jiffies.
> 
> Since commit a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are
> negative"), ___ratelimit() splats on such values, so the next
> net_ratelimit() caller warns, e.g. a martian source log:
> 
>   Negative interval (-250) or burst (10): Uninitialized ratelimit_state structure?
>   WARNING: lib/ratelimit.c:43 at ___ratelimit+0x56e/0x960, CPU#1: ping/3218
>   RIP: 0010:___ratelimit+0x578/0x960
>   Call Trace:
>    <IRQ>
>    net_ratelimit+0x1c/0x30
>    ip_handle_martian_source+0x1bb/0x340
>    ip_route_input_slow+0x1057/0x3650
>    ip_route_input_noref+0x104/0x260
>    arp_process+0x109b/0x2510
>    arp_rcv+0x381/0x460
>    __netif_receive_skb_one_core+0x173/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
>    do_softirq.part.0+0x49/0xd0
>    </IRQ>
> 
> Negative values never meant anything here: ___ratelimit() treats them
> like 0, and 0 already expresses both "no limit" (interval) and
> "suppress everything" (burst).
> 
> Reject them at write time. message_burst can simply use
> proc_dointvec_minmax with extra1 = 0. proc_dointvec_jiffies ignores
> extra1/extra2, so give message_cost a small handler that parses into a
> temporary and only stores the value if it is not negative.
> 
> Fixes: a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are negative")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  net/core/sysctl_net_core.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> index 473c162736d6..8146ed819695 100644
> --- a/net/core/sysctl_net_core.c
> +++ b/net/core/sysctl_net_core.c
> @@ -378,6 +378,22 @@ static int proc_do_skb_defer_max(const struct ctl_table *table, int write,
>  	return ret;
>  }
>  
> +static int proc_do_message_cost(const struct ctl_table *table, int write,
> +				void *buffer, size_t *lenp, loff_t *ppos)
> +{
> +	int ret, interval = READ_ONCE(*(int *)table->data);
> +	struct ctl_table tmp = *table;
> +
> +	tmp.data = &interval;
> +	ret = proc_dointvec_jiffies(&tmp, write, buffer, lenp, ppos);
> +	if (write && !ret) {
> +		if (interval < 0)
> +			return -EINVAL;
> +		WRITE_ONCE(*(int *)table->data, interval);
> +	}
> +	return ret;
> +}
> +
>  #ifdef CONFIG_BPF_JIT
>  static int proc_dointvec_minmax_bpf_enable(const struct ctl_table *table, int write,
>  					   void *buffer, size_t *lenp,
> @@ -544,14 +560,15 @@ static struct ctl_table net_core_table[] = {
>  		.data		= &net_ratelimit_state.interval,
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
> -		.proc_handler	= proc_dointvec_jiffies,
> +		.proc_handler	= proc_do_message_cost,
>  	},
>  	{
>  		.procname	= "message_burst",
>  		.data		= &net_ratelimit_state.burst,
>  		.maxlen		= sizeof(int),
>  		.mode		= 0644,
> -		.proc_handler	= proc_dointvec,
> +		.proc_handler	= proc_dointvec_minmax,
> +		.extra1		= SYSCTL_ZERO,
>  	},
>  #ifdef CONFIG_RPS
>  	{
> -- 
> 2.43.0
> 

I would prefer something like this [1] (not tested and not compiled).
This is more in line with the patterns inside the jiffies.c file. I put
SYSCTL_ZERO there, but I have a doubt if you actually need SYSCTL_ONE.

If the interval variable can be zero, then leave it as SYSCTL_ZERO, but
if it cant be zero and can be one the use SYSCTL_ONE

best


[1] 

diff --git i/include/linux/jiffies.h w/include/linux/jiffies.h
index bbd57061802c..288ba81ed53e 100644
--- i/include/linux/jiffies.h
+++ w/include/linux/jiffies.h
@@ -646,6 +646,8 @@ extern unsigned long nsecs_to_jiffies(u64 n);
 struct ctl_table;
 int proc_dointvec_jiffies(const struct ctl_table *table, int dir, void *buffer,
                          size_t *lenp, loff_t *ppos);
+int proc_dointvec_jiffies_minmax(const struct ctl_table *table, int dir, void *buffer,
+                                size_t *lenp, loff_t *ppos);
 int proc_dointvec_ms_jiffies_minmax(const struct ctl_table *table, int dir,
                                    void *buffer, size_t *lenp, loff_t *ppos);
 int proc_dointvec_userhz_jiffies(const struct ctl_table *table, int dir,
diff --git i/kernel/time/jiffies.c w/kernel/time/jiffies.c
index 9b3487d40cd6..cf91996fe4e3 100644
--- i/kernel/time/jiffies.c
+++ w/kernel/time/jiffies.c
@@ -165,6 +165,14 @@ static int do_proc_int_conv_jiffies(bool *negp, ulong *u_ptr, int *k_ptr,
                             sysctl_u2k_int_conv_hz, sysctl_k2u_int_conv_hz);
 }

+static int do_proc_int_conv_jiffies_minmax(bool *negp, ulong *u_ptr, int *k_ptr,
+                                   int dir, const struct ctl_table *tbl)
+{
+       return proc_int_conv(negp, u_ptr, k_ptr, dir, tbl, true,
+                            sysctl_u2k_int_conv_hz, sysctl_k2u_int_conv_hz);
+}
+
+
 static int do_proc_int_conv_userhz_jiffies(bool *negp, ulong *u_ptr,
                                           int *k_ptr, int dir,
                                           const struct ctl_table *tbl)
@@ -263,6 +271,15 @@ int proc_dointvec_jiffies(const struct ctl_table *table, int dir,
 }
 EXPORT_SYMBOL(proc_dointvec_jiffies);

+int proc_dointvec_jiffies_minmax(const struct ctl_table *table, int dir,
+                         void *buffer, size_t *lenp, loff_t *ppos)
+{
+       return proc_dointvec_conv(table, dir, buffer, lenp, ppos,
+                                 do_proc_int_conv_jiffies_minmax);
+}
+EXPORT_SYMBOL(proc_dointvec_jiffies);
+
+
 /**
  * proc_dointvec_userhz_jiffies - read a vector of integers as 1/USER_HZ seconds
  * @table: the sysctl table
diff --git i/net/core/sysctl_net_core.c w/net/core/sysctl_net_core.c
index eb35da3556f4..7226697bf7c1 100644
--- i/net/core/sysctl_net_core.c
+++ w/net/core/sysctl_net_core.c
@@ -538,7 +538,8 @@ static struct ctl_table net_core_table[] = {
                .data           = &net_ratelimit_state.interval,
                .maxlen         = sizeof(int),
                .mode           = 0644,
-               .proc_handler   = proc_dointvec_jiffies,
+               .proc_handler   = proc_dointvec_jiffies_minmax,
+               .extra1         = SYSCTL_ZERO,
        },
        {
                .procname       = "message_burst",

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH net 5/5] net: restrict message_cost and message_burst to non-negative values

[Fernando Fernandez Mancera]

On 10/23/26 2:19 PM, Joel Granados wrote:
> On Fri, Oct 23, 2026 at 05:13:31PM +0800, Jiayuan Chen wrote:
>> net.core.message_cost and net.core.message_burst feed the interval and
>> burst of net_ratelimit_state, but neither has a lower bound:
>> message_burst uses plain proc_dointvec, and message_cost uses
>> proc_dointvec_jiffies, which happily stores -1 second as -HZ jiffies.
>>
>> Since commit a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are
>> negative"), ___ratelimit() splats on such values, so the next
>> net_ratelimit() caller warns, e.g. a martian source log:
>>
>>    Negative interval (-250) or burst (10): Uninitialized ratelimit_state structure?
>>    WARNING: lib/ratelimit.c:43 at ___ratelimit+0x56e/0x960, CPU#1: ping/3218
>>    RIP: 0010:___ratelimit+0x578/0x960
>>    Call Trace:
>>     <IRQ>
>>     net_ratelimit+0x1c/0x30
>>     ip_handle_martian_source+0x1bb/0x340
>>     ip_route_input_slow+0x1057/0x3650
>>     ip_route_input_noref+0x104/0x260
>>     arp_process+0x109b/0x2510
>>     arp_rcv+0x381/0x460
>>     __netif_receive_skb_one_core+0x173/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
>>     do_softirq.part.0+0x49/0xd0
>>     </IRQ>
>>
>> Negative values never meant anything here: ___ratelimit() treats them
>> like 0, and 0 already expresses both "no limit" (interval) and
>> "suppress everything" (burst).
>>
>> Reject them at write time. message_burst can simply use
>> proc_dointvec_minmax with extra1 = 0. proc_dointvec_jiffies ignores
>> extra1/extra2, so give message_cost a small handler that parses into a
>> temporary and only stores the value if it is not negative.
>>
>> Fixes: a940d145cc38 ("ratelimit: Warn if ->interval or ->burst are negative")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>> ---
>>   net/core/sysctl_net_core.c | 21 +++++++++++++++++++--
>>   1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
>> index 473c162736d6..8146ed819695 100644
>> --- a/net/core/sysctl_net_core.c
>> +++ b/net/core/sysctl_net_core.c
>> @@ -378,6 +378,22 @@ static int proc_do_skb_defer_max(const struct ctl_table *table, int write,
>>   	return ret;
>>   }
>>   
>> +static int proc_do_message_cost(const struct ctl_table *table, int write,
>> +				void *buffer, size_t *lenp, loff_t *ppos)
>> +{
>> +	int ret, interval = READ_ONCE(*(int *)table->data);
>> +	struct ctl_table tmp = *table;
>> +
>> +	tmp.data = &interval;
>> +	ret = proc_dointvec_jiffies(&tmp, write, buffer, lenp, ppos);
>> +	if (write && !ret) {
>> +		if (interval < 0)
>> +			return -EINVAL;
>> +		WRITE_ONCE(*(int *)table->data, interval);
>> +	}
>> +	return ret;
>> +}
>> +
>>   #ifdef CONFIG_BPF_JIT
>>   static int proc_dointvec_minmax_bpf_enable(const struct ctl_table *table, int write,
>>   					   void *buffer, size_t *lenp,
>> @@ -544,14 +560,15 @@ static struct ctl_table net_core_table[] = {
>>   		.data		= &net_ratelimit_state.interval,
>>   		.maxlen		= sizeof(int),
>>   		.mode		= 0644,
>> -		.proc_handler	= proc_dointvec_jiffies,
>> +		.proc_handler	= proc_do_message_cost,
>>   	},
>>   	{
>>   		.procname	= "message_burst",
>>   		.data		= &net_ratelimit_state.burst,
>>   		.maxlen		= sizeof(int),
>>   		.mode		= 0644,
>> -		.proc_handler	= proc_dointvec,
>> +		.proc_handler	= proc_dointvec_minmax,
>> +		.extra1		= SYSCTL_ZERO,
>>   	},
>>   #ifdef CONFIG_RPS
>>   	{
>> -- 
>> 2.43.0
>>
> 
> I would prefer something like this [1] (not tested and not compiled).
> This is more in line with the patterns inside the jiffies.c file. I put
> SYSCTL_ZERO there, but I have a doubt if you actually need SYSCTL_ONE.
> 
> If the interval variable can be zero, then leave it as SYSCTL_ZERO, but
> if it cant be zero and can be one the use SYSCTL_ONE
> 

FWIW, I also like this solution and indeed we can convert other users in 
the future.

About SYSCTL_ZERO, I believe it is the right choice. AFAIU, it just 
disables limiting.

Thanks,
Fernando.

> best
> 
> 
> [1]
> 
> diff --git i/include/linux/jiffies.h w/include/linux/jiffies.h
> index bbd57061802c..288ba81ed53e 100644
> --- i/include/linux/jiffies.h
> +++ w/include/linux/jiffies.h
> @@ -646,6 +646,8 @@ extern unsigned long nsecs_to_jiffies(u64 n);
>   struct ctl_table;
>   int proc_dointvec_jiffies(const struct ctl_table *table, int dir, void *buffer,
>                            size_t *lenp, loff_t *ppos);
> +int proc_dointvec_jiffies_minmax(const struct ctl_table *table, int dir, void *buffer,
> +                                size_t *lenp, loff_t *ppos);
>   int proc_dointvec_ms_jiffies_minmax(const struct ctl_table *table, int dir,
>                                      void *buffer, size_t *lenp, loff_t *ppos);
>   int proc_dointvec_userhz_jiffies(const struct ctl_table *table, int dir,
> diff --git i/kernel/time/jiffies.c w/kernel/time/jiffies.c
> index 9b3487d40cd6..cf91996fe4e3 100644
> --- i/kernel/time/jiffies.c
> +++ w/kernel/time/jiffies.c
> @@ -165,6 +165,14 @@ static int do_proc_int_conv_jiffies(bool *negp, ulong *u_ptr, int *k_ptr,
>                               sysctl_u2k_int_conv_hz, sysctl_k2u_int_conv_hz);
>   }
> 
> +static int do_proc_int_conv_jiffies_minmax(bool *negp, ulong *u_ptr, int *k_ptr,
> +                                   int dir, const struct ctl_table *tbl)
> +{
> +       return proc_int_conv(negp, u_ptr, k_ptr, dir, tbl, true,
> +                            sysctl_u2k_int_conv_hz, sysctl_k2u_int_conv_hz);
> +}
> +
> +
>   static int do_proc_int_conv_userhz_jiffies(bool *negp, ulong *u_ptr,
>                                             int *k_ptr, int dir,
>                                             const struct ctl_table *tbl)
> @@ -263,6 +271,15 @@ int proc_dointvec_jiffies(const struct ctl_table *table, int dir,
>   }
>   EXPORT_SYMBOL(proc_dointvec_jiffies);
> 
> +int proc_dointvec_jiffies_minmax(const struct ctl_table *table, int dir,
> +                         void *buffer, size_t *lenp, loff_t *ppos)
> +{
> +       return proc_dointvec_conv(table, dir, buffer, lenp, ppos,
> +                                 do_proc_int_conv_jiffies_minmax);
> +}
> +EXPORT_SYMBOL(proc_dointvec_jiffies);
> +
> +
>   /**
>    * proc_dointvec_userhz_jiffies - read a vector of integers as 1/USER_HZ seconds
>    * @table: the sysctl table
> diff --git i/net/core/sysctl_net_core.c w/net/core/sysctl_net_core.c
> index eb35da3556f4..7226697bf7c1 100644
> --- i/net/core/sysctl_net_core.c
> +++ w/net/core/sysctl_net_core.c
> @@ -538,7 +538,8 @@ static struct ctl_table net_core_table[] = {
>                  .data           = &net_ratelimit_state.interval,
>                  .maxlen         = sizeof(int),
>                  .mode           = 0644,
> -               .proc_handler   = proc_dointvec_jiffies,
> +               .proc_handler   = proc_dointvec_jiffies_minmax,
> +               .extra1         = SYSCTL_ZERO,
>          },
>          {
>                  .procname       = "message_burst",

Re: [PATCH net 5/5] net: restrict message_cost and message_burst to non-negative values

[Jiayuan Chen]

On 10/23/26 8:55 PM, Fernando Fernandez Mancera wrote:
[...]
>>>   #ifdef CONFIG_BPF_JIT
>>>   static int proc_dointvec_minmax_bpf_enable(const struct ctl_table 
>>> *table, int write,
>>>                          void *buffer, size_t *lenp,
>>> @@ -544,14 +560,15 @@ static struct ctl_table net_core_table[] = {
>>>           .data        = &net_ratelimit_state.interval,
>>>           .maxlen        = sizeof(int),
>>>           .mode        = 0644,
>>> -        .proc_handler    = proc_dointvec_jiffies,
>>> +        .proc_handler    = proc_do_message_cost,
>>>       },
>>>       {
>>>           .procname    = "message_burst",
>>>           .data        = &net_ratelimit_state.burst,
>>>           .maxlen        = sizeof(int),
>>>           .mode        = 0644,
>>> -        .proc_handler    = proc_dointvec,
>>> +        .proc_handler    = proc_dointvec_minmax,
>>> +        .extra1        = SYSCTL_ZERO,
>>>       },
>>>   #ifdef CONFIG_RPS
>>>       {
>>> -- 
>>> 2.43.0
>>>
>>
>> I would prefer something like this [1] (not tested and not compiled).
>> This is more in line with the patterns inside the jiffies.c file. I put
>> SYSCTL_ZERO there, but I have a doubt if you actually need SYSCTL_ONE.
>>

Thanks Joel and Fernando, good to hear this.

I actually had almost the same proc_dointvec_jiffies_minmax() locally at 
first,

but then thought "this touches sysctl core, better not" and went with 
the local handler
instead.

Glad I was wrong about that :)


>> If the interval variable can be zero, then leave it as SYSCTL_ZERO, but
>> if it cant be zero and can be one the use SYSCTL_ONE
>>
>
> FWIW, I also like this solution and indeed we can convert other users 
> in the future.
>
> About SYSCTL_ZERO, I believe it is the right choice. AFAIU, it just 
> disables limiting.
>

Agreed on SYSCTL_ZERO. interval == 0 is the documented "never limit"
case in ___ratelimit(), so it has to stay allowed.


> Thanks,
> Fernando.
>