[syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    cc17b4b9c332 Merge branch 'io_uring-zcrx-fix-selftests-and..
git tree:       net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10ab50d4580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=7e367ce4a19f69ba
dashboard link: https://syzkaller.appspot.com/bug?extid=8f8024317adff163ec5a
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17e2a270580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=145a9d74580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0e09cf367bdd/disk-cc17b4b9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4ab63344d74c/vmlinux-cc17b4b9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/14915e0e32b3/bzImage-cc17b4b9.xz

The issue was bisected to:

commit 557f8c582a9ba8abe6aa0fd734b6f342af106b26
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Jan 18 23:06:05 2024 +0000

    ubsan: Reintroduce signed overflow sanitizer

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1685d270580000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=1585d270580000
console output: https://syzkaller.appspot.com/x/log.txt?x=1185d270580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8f8024317adff163ec5a@syzkaller.appspotmail.com
Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer")

------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in net/ipv6/route.c:1095:9
index 255 is out of range for type 'const int[12]'
CPU: 1 UID: 0 PID: 5835 Comm: kworker/1:3 Not tainted 6.15.0-rc3-syzkaller-00584-gcc17b4b9c332 #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/19/2025
Workqueue: mld mld_ifc_work
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 ubsan_epilogue+0xa/0x40 lib/ubsan.c:231
 __ubsan_handle_out_of_bounds+0xe9/0xf0 lib/ubsan.c:453
 ip6_rt_type_to_error net/ipv6/route.c:1095 [inline]
 ip6_rt_init_dst_reject net/ipv6/route.c:1112 [inline]
 ip6_rt_init_dst net/ipv6/route.c:1137 [inline]
 ip6_rt_copy_init+0x8e7/0x970 net/ipv6/route.c:1175
 ip6_rt_pcpu_alloc net/ipv6/route.c:1424 [inline]
 rt6_make_pcpu_route net/ipv6/route.c:1467 [inline]
 ip6_pol_route+0xbac/0x1180 net/ipv6/route.c:2302
 pol_lookup_func include/net/ip6_fib.h:617 [inline]
 fib6_rule_lookup+0x348/0x6f0 net/ipv6/fib6_rules.c:125
 ip6_route_output_flags_noref net/ipv6/route.c:2674 [inline]
 ip6_route_output_flags+0x364/0x5d0 net/ipv6/route.c:2686
 ip6_route_output include/net/ip6_route.h:93 [inline]
 ip6_dst_lookup_tail+0x1ae/0x1510 net/ipv6/ip6_output.c:1128
 ip6_dst_lookup_flow+0x47/0xe0 net/ipv6/ip6_output.c:1259
 udp_tunnel6_dst_lookup+0x231/0x3c0 net/ipv6/ip6_udp_tunnel.c:165
 geneve6_xmit_skb drivers/net/geneve.c:957 [inline]
 geneve_xmit+0xd2e/0x2b70 drivers/net/geneve.c:1043
 __netdev_start_xmit include/linux/netdevice.h:5203 [inline]
 netdev_start_xmit include/linux/netdevice.h:5212 [inline]
 xmit_one net/core/dev.c:3828 [inline]
 dev_hard_start_xmit+0x2d4/0x830 net/core/dev.c:3844
 __dev_queue_xmit+0x1adf/0x3a70 net/core/dev.c:4681
 dev_queue_xmit include/linux/netdevice.h:3349 [inline]
 neigh_hh_output include/net/neighbour.h:523 [inline]
 neigh_output include/net/neighbour.h:537 [inline]
 ip6_finish_output2+0x11bc/0x16a0 net/ipv6/ip6_output.c:141
 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]
 ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:226
 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:314
 mld_sendpack+0x800/0xd80 net/ipv6/mcast.c:1868
 mld_send_cr net/ipv6/mcast.c:2169 [inline]
 mld_ifc_work+0x835/0xde0 net/ipv6/mcast.c:2702
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xadb/0x17a0 kernel/workqueue.c:3319
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
---[ end trace ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[Kees Cook]

On Thu, May 01, 2025 at 04:14:30AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    cc17b4b9c332 Merge branch 'io_uring-zcrx-fix-selftests-and..
> git tree:       net-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=10ab50d4580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7e367ce4a19f69ba
> dashboard link: https://syzkaller.appspot.com/bug?extid=8f8024317adff163ec5a
> compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17e2a270580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=145a9d74580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/0e09cf367bdd/disk-cc17b4b9.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/4ab63344d74c/vmlinux-cc17b4b9.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/14915e0e32b3/bzImage-cc17b4b9.xz
> 
> The issue was bisected to:
> 
> commit 557f8c582a9ba8abe6aa0fd734b6f342af106b26
> Author: Kees Cook <keescook@chromium.org>
> Date:   Thu Jan 18 23:06:05 2024 +0000
> 
>     ubsan: Reintroduce signed overflow sanitizer

Why _this_ patch exposes this, I'm not exactly sure, but ...

> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1685d270580000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=1585d270580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1185d270580000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8f8024317adff163ec5a@syzkaller.appspotmail.com
> Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer")
> 
> ------------[ cut here ]------------
> UBSAN: array-index-out-of-bounds in net/ipv6/route.c:1095:9
> index 255 is out of range for type 'const int[12]'

... it looks like a real problem. fib6_type is 255, but the array is
small, causing an out-of-bounds read past the end of the array further
into .rodata:

static int ip6_rt_type_to_error(u8 fib6_type)
{
        return fib6_prop[fib6_type];
}

Perhaps some kind of type confusion, as this is being generated through
ip6_rt_init_dst_reject(). Is the fib6_type not "valid" on a reject?

The reproducer appears to be just absolutely spamming netlink with
requests -- it's not at all obvious to me where the fib6_type is even
coming from. I think this is already only reachable on the error path
(i.e. it's during a "reject", it looks like), so the rt->dst.error is
just being set weird.

This feels like it's papering over the actual problem:

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 96f1621e2381..fba51a42e7ac 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1092,6 +1092,8 @@ static const int fib6_prop[RTN_MAX + 1] = {
 
 static int ip6_rt_type_to_error(u8 fib6_type)
 {
+	if (fib6_type > RTN_MAX)
+		return -EINVAL;
 	return fib6_prop[fib6_type];
 }
 

-Kees

> CPU: 1 UID: 0 PID: 5835 Comm: kworker/1:3 Not tainted 6.15.0-rc3-syzkaller-00584-gcc17b4b9c332 #0 PREEMPT(full) 
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/19/2025
> Workqueue: mld mld_ifc_work
> Call Trace:
>  <TASK>
>  dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
>  ubsan_epilogue+0xa/0x40 lib/ubsan.c:231
>  __ubsan_handle_out_of_bounds+0xe9/0xf0 lib/ubsan.c:453
>  ip6_rt_type_to_error net/ipv6/route.c:1095 [inline]
>  ip6_rt_init_dst_reject net/ipv6/route.c:1112 [inline]
>  ip6_rt_init_dst net/ipv6/route.c:1137 [inline]
>  ip6_rt_copy_init+0x8e7/0x970 net/ipv6/route.c:1175
>  ip6_rt_pcpu_alloc net/ipv6/route.c:1424 [inline]
>  rt6_make_pcpu_route net/ipv6/route.c:1467 [inline]
>  ip6_pol_route+0xbac/0x1180 net/ipv6/route.c:2302
>  pol_lookup_func include/net/ip6_fib.h:617 [inline]
>  fib6_rule_lookup+0x348/0x6f0 net/ipv6/fib6_rules.c:125
>  ip6_route_output_flags_noref net/ipv6/route.c:2674 [inline]
>  ip6_route_output_flags+0x364/0x5d0 net/ipv6/route.c:2686
>  ip6_route_output include/net/ip6_route.h:93 [inline]
>  ip6_dst_lookup_tail+0x1ae/0x1510 net/ipv6/ip6_output.c:1128
>  ip6_dst_lookup_flow+0x47/0xe0 net/ipv6/ip6_output.c:1259
>  udp_tunnel6_dst_lookup+0x231/0x3c0 net/ipv6/ip6_udp_tunnel.c:165
>  geneve6_xmit_skb drivers/net/geneve.c:957 [inline]
>  geneve_xmit+0xd2e/0x2b70 drivers/net/geneve.c:1043
>  __netdev_start_xmit include/linux/netdevice.h:5203 [inline]
>  netdev_start_xmit include/linux/netdevice.h:5212 [inline]
>  xmit_one net/core/dev.c:3828 [inline]
>  dev_hard_start_xmit+0x2d4/0x830 net/core/dev.c:3844
>  __dev_queue_xmit+0x1adf/0x3a70 net/core/dev.c:4681
>  dev_queue_xmit include/linux/netdevice.h:3349 [inline]
>  neigh_hh_output include/net/neighbour.h:523 [inline]
>  neigh_output include/net/neighbour.h:537 [inline]
>  ip6_finish_output2+0x11bc/0x16a0 net/ipv6/ip6_output.c:141
>  __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]
>  ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:226
>  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:314
>  mld_sendpack+0x800/0xd80 net/ipv6/mcast.c:1868
>  mld_send_cr net/ipv6/mcast.c:2169 [inline]
>  mld_ifc_work+0x835/0xde0 net/ipv6/mcast.c:2702
>  process_one_work kernel/workqueue.c:3238 [inline]
>  process_scheduled_works+0xadb/0x17a0 kernel/workqueue.c:3319
>  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400
>  kthread+0x70e/0x8a0 kernel/kthread.c:464
>  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>  </TASK>
> ---[ end trace ]---
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup

-- 
Kees Cook

Re: [syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[David Ahern]

On 5/1/25 2:12 PM, Kees Cook wrote:
> static int ip6_rt_type_to_error(u8 fib6_type)
> {
>         return fib6_prop[fib6_type];
> }
> 
> Perhaps some kind of type confusion, as this is being generated through
> ip6_rt_init_dst_reject(). Is the fib6_type not "valid" on a reject?

fib6_result is initialized to 0 in ip6_pol_route and no setting of
fib6_type should be > RTN_MAX.

> 
> The reproducer appears to be just absolutely spamming netlink with
> requests -- it's not at all obvious to me where the fib6_type is even
> coming from. I think this is already only reachable on the error path
> (i.e. it's during a "reject", it looks like), so the rt->dst.error is
> just being set weird.
> 
> This feels like it's papering over the actual problem:

yes, if fib6_type is > than RTN_MAX we need to understand where that is
happening.

> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 96f1621e2381..fba51a42e7ac 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1092,6 +1092,8 @@ static const int fib6_prop[RTN_MAX + 1] = {
>  
>  static int ip6_rt_type_to_error(u8 fib6_type)
>  {
> +	if (fib6_type > RTN_MAX)
> +		return -EINVAL;
>  	return fib6_prop[fib6_type];
>  }
>  
> 
> -Kees
> 

Re: [syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[Kuniyuki Iwashima]

From: David Ahern <dsahern@kernel.org>
Date: Thu, 1 May 2025 14:44:03 -0600
> On 5/1/25 2:12 PM, Kees Cook wrote:
> > static int ip6_rt_type_to_error(u8 fib6_type)
> > {
> >         return fib6_prop[fib6_type];
> > }
> > 
> > Perhaps some kind of type confusion, as this is being generated through
> > ip6_rt_init_dst_reject(). Is the fib6_type not "valid" on a reject?
> 
> fib6_result is initialized to 0 in ip6_pol_route and no setting of
> fib6_type should be > RTN_MAX.
> 
> > 
> > The reproducer appears to be just absolutely spamming netlink with
> > requests -- it's not at all obvious to me where the fib6_type is even
> > coming from. I think this is already only reachable on the error path
> > (i.e. it's during a "reject", it looks like), so the rt->dst.error is
> > just being set weird.
> > 
> > This feels like it's papering over the actual problem:
> 
> yes, if fib6_type is > than RTN_MAX we need to understand where that is
> happening.

Sorry, I think this was my mistake,
https://lore.kernel.org/netdev/20250502002616.60759-1-kuniyu@amazon.com/T/#t

and this will fix it.
https://lore.kernel.org/netdev/20250501005335.53683-1-kuniyu@amazon.com/

Thanks!


#syz dup: [syzbot] [net?] WARNING in ipv6_addr_prefix

Re: [syzbot] [net?] UBSAN: array-index-out-of-bounds in ip6_rt_copy_init

[Kees Cook]

On Thu, May 01, 2025 at 06:15:28PM -0700, Kuniyuki Iwashima wrote:
> From: David Ahern <dsahern@kernel.org>
> Date: Thu, 1 May 2025 14:44:03 -0600
> > On 5/1/25 2:12 PM, Kees Cook wrote:
> > > static int ip6_rt_type_to_error(u8 fib6_type)
> > > {
> > >         return fib6_prop[fib6_type];
> > > }
> > > 
> > > Perhaps some kind of type confusion, as this is being generated through
> > > ip6_rt_init_dst_reject(). Is the fib6_type not "valid" on a reject?
> > 
> > fib6_result is initialized to 0 in ip6_pol_route and no setting of
> > fib6_type should be > RTN_MAX.
> > 
> > > 
> > > The reproducer appears to be just absolutely spamming netlink with
> > > requests -- it's not at all obvious to me where the fib6_type is even
> > > coming from. I think this is already only reachable on the error path
> > > (i.e. it's during a "reject", it looks like), so the rt->dst.error is
> > > just being set weird.
> > > 
> > > This feels like it's papering over the actual problem:
> > 
> > yes, if fib6_type is > than RTN_MAX we need to understand where that is
> > happening.
> 
> Sorry, I think this was my mistake,
> https://lore.kernel.org/netdev/20250502002616.60759-1-kuniyu@amazon.com/T/#t
> 
> and this will fix it.
> https://lore.kernel.org/netdev/20250501005335.53683-1-kuniyu@amazon.com/
> 
> Thanks!
> 
> 
> #syz dup: [syzbot] [net?] WARNING in ipv6_addr_prefix

Ah-ha! Thanks for getting it fixed! :)

-- 
Kees Cook