linux-kernel - Re: BUG: corrupted list in dst

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CANikGpcm2ytALYjKG9n05Pe2LJJvoYNuMr-bCPFSB7V4twgYdg@mail.gmail.com>
Date: Thu, 29 Aug 2024 12:30:52 -0700
From: Juefei Pu <juefei.pu@...il.ucr.edu>
To: Juefei Pu <juefei.pu@...il.ucr.edu>
Cc: Bart Van Assche <bvanassche@....org>, James.Bottomley@...senpartnership.com, 
	Yu Hao <yhao016@....edu>, linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org, 
	martin.petersen@...cle.com
Subject: Re: BUG: corrupted list in dst_init

Syzkaller uses `syz-executor` to fuzz, but inside the call trace , the
program that went wrong is  `swapper`.  After checking the reproducer,
the `/dev/sg0` seems the most suspicious one since it provides users
with direct access to hardware.

My hypothesis is such access can somehow tamper the memory without
being caught by KASAN, and it just so happen in this particular case,
the victim is ` ip6_dst_alloc`.

So I feel that maybe sending the mail to SCSI maintainers is the right choice.

On Thu, Aug 29, 2024 at 11:44 AM Juefei Pu <juefei.pu@...il.ucr.edu> wrote:
>
> Syzkaller uses `syz-executor` to fuzz, but inside the call trace , the program that went wrong is  `swapper`.  After checking the reproducer, the `/dev/sg0` seems the most suspicious one since it provides user with direct access to hardware.
>
> My hypothesis is such access can somehow tamper the memory without being caught by KASAN, and it just so happen in this particular case, the victim is ` ip6_dst_alloc`.
>
> So I feel that maybe sending the mail to SCSI maintainers is the right choice.
>
>
> On Thu, Aug 29, 2024 at 4:07 AM Bart Van Assche <bvanassche@....org> wrote:
> >
> > On 8/29/24 2:31 AM, Juefei Pu wrote:
> > > Call Trace:
> > >   <IRQ>
> > >   __list_add_valid include/linux/list.h:88 [inline]
> > >   __list_add include/linux/list.h:150 [inline]
> > >   list_add include/linux/list.h:169 [inline]
> > >   ref_tracker_alloc+0x1ef/0x480 lib/ref_tracker.c:213
> > >   __netdev_tracker_alloc include/linux/netdevice.h:4038 [inline]
> > >   netdev_hold include/linux/netdevice.h:4067 [inline]
> > >   dst_init+0xea/0x480 net/core/dst.c:52
> > >   dst_alloc+0x157/0x190 net/core/dst.c:93
> > >   ip6_dst_alloc net/ipv6/route.c:344 [inline]
> > >   icmp6_dst_alloc+0x73/0x410 net/ipv6/route.c:3277
> > >   ndisc_send_skb+0x31b/0x11e0 net/ipv6/ndisc.c:489
> > >   addrconf_rs_timer+0x3a3/0x650 net/ipv6/addrconf.c:4039
> > >   call_timer_fn+0xff/0x240 kernel/time/timer.c:1792
> > >   expire_timers kernel/time/timer.c:1843 [inline]
> > >   __run_timers kernel/time/timer.c:2417 [inline]
> > >   __run_timer_base+0x734/0x9a0 kernel/time/timer.c:2428
> > >   run_timer_base kernel/time/timer.c:2437 [inline]
> > >   run_timer_softirq+0xb3/0x160 kernel/time/timer.c:2447
> > >   handle_softirqs+0x272/0x750 kernel/softirq.c:554
> > >   __do_softirq kernel/softirq.c:588 [inline]
> > >   invoke_softirq kernel/softirq.c:428 [inline]
> > >   __irq_exit_rcu+0xf0/0x1b0 kernel/softirq.c:637
> > >   irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> > >   instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
> > >   sysvec_apic_timer_interrupt+0xa0/0xc0 arch/x86/kernel/apic/apic.c:1043
> > >   </IRQ>
> >
> > I see networking functions in the above call stack. Why has this report
> > been sent to the SCSI maintainers?
> >
> > Thanks,
> >
> > Bart.
> >