mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH net] bonding: fix out-of-bounds read of arp_ip_target
@ 2026-10-23 10:45 Jiayuan Chen
  2026-10-23 11:22 ` Fernando Fernandez Mancera
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jiayuan Chen @ 2026-10-23 10:45 UTC (permalink / raw)
  To: netdev
  Cc: Jiayuan Chen, stable, Jay Vosburgh, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Nikolay Aleksandrov,
	linux-kernel

arp_ip_target is a module parameter array with BOND_MAX_ARP_TARGETS
entries. In the loop parsing it in bond_check_params(), arp_ip_count is
the number of accepted targets, while i is the index into
arp_ip_target. Invalid and duplicate entries are skipped without
bumping arp_ip_count, so bounding the loop with arp_ip_count lets i run
past the end of arp_ip_target, e.g. 16 targets with one duplicate:

  BUG: KASAN: global-out-of-bounds in bond_check_params.constprop.0+0x1148/0x1440
  Read of size 8 at addr ffffffff96e9ee00 by task swapper/0/1
  Call Trace:
   <TASK>
   dump_stack_lvl+0x91/0xf0
   print_report+0xd1/0x630
   kasan_report+0xf3/0x130
   __asan_report_load8_noabort+0x14/0x30
   bond_check_params.constprop.0+0x1148/0x1440
   bonding_init+0x13/0xe0
   do_one_initcall+0xe7/0x5b0
   kernel_init_freeable+0xa91/0x1120
   kernel_init+0x24/0x220
   ret_from_fork+0x5b3/0x820
   ret_from_fork_asm+0x1a/0x30
   </TASK>

  The buggy address belongs to the variable:
   arp_ip_target+0x80/0xa0

Bound the loop with i instead. arp_ip_count never exceeds i, so it
stays within BOND_MAX_ARP_TARGETS too.

Fixes: 5a5c5fd48e3b ("bonding: arp_ip_count and arp_targets can be wrong")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 drivers/net/bonding/bond_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 09aa45d71fab..7019e5d8fdc8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -6273,7 +6273,7 @@ static int __init bond_check_params(struct bond_params *params)
 	}
 
 	for (arp_ip_count = 0, i = 0;
-	     (arp_ip_count < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
+	     (i < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
 		__be32 ip;
 
 		/* not a complete check, but good enough to catch mistakes */
-- 
2.43.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net] bonding: fix out-of-bounds read of arp_ip_target
  2026-10-23 10:45 [PATCH net] bonding: fix out-of-bounds read of arp_ip_target Jiayuan Chen
@ 2026-10-23 11:22 ` Fernando Fernandez Mancera
  2026-10-23 11:55 ` Nikolay Aleksandrov
  2026-10-23 13:12 ` Jay Vosburgh
  2 siblings, 0 replies; 4+ messages in thread
From: Fernando Fernandez Mancera @ 2026-10-23 11:22 UTC (permalink / raw)
  To: Jiayuan Chen, netdev
  Cc: stable, Jay Vosburgh, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Nikolay Aleksandrov, linux-kernel

On 10/23/26 12:45 PM, Jiayuan Chen wrote:
> arp_ip_target is a module parameter array with BOND_MAX_ARP_TARGETS
> entries. In the loop parsing it in bond_check_params(), arp_ip_count is
> the number of accepted targets, while i is the index into
> arp_ip_target. Invalid and duplicate entries are skipped without
> bumping arp_ip_count, so bounding the loop with arp_ip_count lets i run
> past the end of arp_ip_target, e.g. 16 targets with one duplicate:
> 
>    BUG: KASAN: global-out-of-bounds in bond_check_params.constprop.0+0x1148/0x1440
>    Read of size 8 at addr ffffffff96e9ee00 by task swapper/0/1
>    Call Trace:
>     <TASK>
>     dump_stack_lvl+0x91/0xf0
>     print_report+0xd1/0x630
>     kasan_report+0xf3/0x130
>     __asan_report_load8_noabort+0x14/0x30
>     bond_check_params.constprop.0+0x1148/0x1440
>     bonding_init+0x13/0xe0
>     do_one_initcall+0xe7/0x5b0
>     kernel_init_freeable+0xa91/0x1120
>     kernel_init+0x24/0x220
>     ret_from_fork+0x5b3/0x820
>     ret_from_fork_asm+0x1a/0x30
>     </TASK>
> 
>    The buggy address belongs to the variable:
>     arp_ip_target+0x80/0xa0
> 
> Bound the loop with i instead. arp_ip_count never exceeds i, so it
> stays within BOND_MAX_ARP_TARGETS too.
> 
> Fixes: 5a5c5fd48e3b ("bonding: arp_ip_count and arp_targets can be wrong")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

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

Thanks!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net] bonding: fix out-of-bounds read of arp_ip_target
  2026-10-23 10:45 [PATCH net] bonding: fix out-of-bounds read of arp_ip_target Jiayuan Chen
  2026-10-23 11:22 ` Fernando Fernandez Mancera
@ 2026-10-23 11:55 ` Nikolay Aleksandrov
  2026-10-23 13:12 ` Jay Vosburgh
  2 siblings, 0 replies; 4+ messages in thread
From: Nikolay Aleksandrov @ 2026-10-23 11:55 UTC (permalink / raw)
  To: Jiayuan Chen, netdev
  Cc: stable, Jay Vosburgh, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, linux-kernel

On 23/10/2026 13:45, Jiayuan Chen wrote:
> arp_ip_target is a module parameter array with BOND_MAX_ARP_TARGETS
> entries. In the loop parsing it in bond_check_params(), arp_ip_count is
> the number of accepted targets, while i is the index into
> arp_ip_target. Invalid and duplicate entries are skipped without
> bumping arp_ip_count, so bounding the loop with arp_ip_count lets i run
> past the end of arp_ip_target, e.g. 16 targets with one duplicate:
> 
>    BUG: KASAN: global-out-of-bounds in bond_check_params.constprop.0+0x1148/0x1440
>    Read of size 8 at addr ffffffff96e9ee00 by task swapper/0/1
>    Call Trace:
>     <TASK>
>     dump_stack_lvl+0x91/0xf0
>     print_report+0xd1/0x630
>     kasan_report+0xf3/0x130
>     __asan_report_load8_noabort+0x14/0x30
>     bond_check_params.constprop.0+0x1148/0x1440
>     bonding_init+0x13/0xe0
>     do_one_initcall+0xe7/0x5b0
>     kernel_init_freeable+0xa91/0x1120
>     kernel_init+0x24/0x220
>     ret_from_fork+0x5b3/0x820
>     ret_from_fork_asm+0x1a/0x30
>     </TASK>
> 
>    The buggy address belongs to the variable:
>     arp_ip_target+0x80/0xa0
> 
> Bound the loop with i instead. arp_ip_count never exceeds i, so it
> stays within BOND_MAX_ARP_TARGETS too.
> 
> Fixes: 5a5c5fd48e3b ("bonding: arp_ip_count and arp_targets can be wrong")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>   drivers/net/bonding/bond_main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 09aa45d71fab..7019e5d8fdc8 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -6273,7 +6273,7 @@ static int __init bond_check_params(struct bond_params *params)
>   	}
>   
>   	for (arp_ip_count = 0, i = 0;
> -	     (arp_ip_count < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
> +	     (i < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
>   		__be32 ip;
>   
>   		/* not a complete check, but good enough to catch mistakes */

Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net] bonding: fix out-of-bounds read of arp_ip_target
  2026-10-23 10:45 [PATCH net] bonding: fix out-of-bounds read of arp_ip_target Jiayuan Chen
  2026-10-23 11:22 ` Fernando Fernandez Mancera
  2026-10-23 11:55 ` Nikolay Aleksandrov
@ 2026-10-23 13:12 ` Jay Vosburgh
  2 siblings, 0 replies; 4+ messages in thread
From: Jay Vosburgh @ 2026-10-23 13:12 UTC (permalink / raw)
  To: Jiayuan Chen
  Cc: netdev, stable, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Nikolay Aleksandrov, linux-kernel

Jiayuan Chen <jiayuan.chen@linux.dev> wrote:

>arp_ip_target is a module parameter array with BOND_MAX_ARP_TARGETS
>entries. In the loop parsing it in bond_check_params(), arp_ip_count is
>the number of accepted targets, while i is the index into
>arp_ip_target. Invalid and duplicate entries are skipped without
>bumping arp_ip_count, so bounding the loop with arp_ip_count lets i run
>past the end of arp_ip_target, e.g. 16 targets with one duplicate:
>
>  BUG: KASAN: global-out-of-bounds in bond_check_params.constprop.0+0x1148/0x1440
>  Read of size 8 at addr ffffffff96e9ee00 by task swapper/0/1
>  Call Trace:
>   <TASK>
>   dump_stack_lvl+0x91/0xf0
>   print_report+0xd1/0x630
>   kasan_report+0xf3/0x130
>   __asan_report_load8_noabort+0x14/0x30
>   bond_check_params.constprop.0+0x1148/0x1440
>   bonding_init+0x13/0xe0
>   do_one_initcall+0xe7/0x5b0
>   kernel_init_freeable+0xa91/0x1120
>   kernel_init+0x24/0x220
>   ret_from_fork+0x5b3/0x820
>   ret_from_fork_asm+0x1a/0x30
>   </TASK>
>
>  The buggy address belongs to the variable:
>   arp_ip_target+0x80/0xa0
>
>Bound the loop with i instead. arp_ip_count never exceeds i, so it
>stays within BOND_MAX_ARP_TARGETS too.
>
>Fixes: 5a5c5fd48e3b ("bonding: arp_ip_count and arp_targets can be wrong")
>Cc: stable@vger.kernel.org
>Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Acked-by: Jay Vosburgh <jv@jvosburgh.net>


>---
> drivers/net/bonding/bond_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 09aa45d71fab..7019e5d8fdc8 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -6273,7 +6273,7 @@ static int __init bond_check_params(struct bond_params *params)
> 	}
> 
> 	for (arp_ip_count = 0, i = 0;
>-	     (arp_ip_count < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
>+	     (i < BOND_MAX_ARP_TARGETS) && arp_ip_target[i]; i++) {
> 		__be32 ip;
> 
> 		/* not a complete check, but good enough to catch mistakes */
>-- 
>2.43.0
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-10-23 13:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-23 10:45 [PATCH net] bonding: fix out-of-bounds read of arp_ip_target Jiayuan Chen
2026-10-23 11:22 ` Fernando Fernandez Mancera
2026-10-23 11:55 ` Nikolay Aleksandrov
2026-10-23 13:12 ` Jay Vosburgh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®