linux-ext4 - Re: [syzbot] [ext4?] possible deadlock in console_flush

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANp29Y5B1VvKbe9Z3Bh-7_3jUSok=q9LO=ibjf9R5iDqEZUBVg@mail.gmail.com>
Date:   Tue, 17 Oct 2023 16:28:09 +0200
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     syzbot <syzbot+f78380e4eae53c64125c@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, bsegall@...gle.com, dvyukov@...gle.com,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        tglx@...utronix.de, tytso@....edu
Subject: Re: [syzbot] [ext4?] possible deadlock in console_flush_all (2)

Thank you for the information!

I've looked closer -- syzbot is currently fuzzing a somewhat old -next
version now (20231005), it could not upgrade after that because of a
-next boot error
(https://syzkaller.appspot.com/bug?extid=6867a9777f4b8dc4e256, already
has a patch). It can explain why we're still seeing these crashes.

Once the fix commit for "linux-next boot error: KASAN:
slab-out-of-bounds Write in vhci_setup" reaches next, it should all be
fine.

And it looks like we should just automatically stop -next fuzzing if
we cannot upgrade the kernel for more than several days in a row..

On Tue, Oct 17, 2023 at 4:16 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Oct 17, 2023 at 06:07:50AM -0700, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:    213f891525c2 Merge tag 'probes-fixes-v6.6-rc6' of git://gi..
>
> > list_add corruption. next->prev should be prev (ffff8880b993d228), but was caff904900000000. (next=ffff8880783659f8).
>
> Urgh, I've not seen that happen before. How reliable does this trigger?
>
> >  __list_add_valid_or_report+0xa2/0x100 lib/list_debug.c:29
> >  __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]
> >  account_entity_enqueue kernel/sched/fair.c:3534 [inline]
> >  enqueue_entity+0x97b/0x1490 kernel/sched/fair.c:5117
> >  enqueue_task_fair+0x15b/0xbc0 kernel/sched/fair.c:6536
> >  enqueue_task kernel/sched/core.c:2102 [inline]
> >  activate_task kernel/sched/core.c:2132 [inline]
> >  ttwu_do_activate+0x214/0xd90 kernel/sched/core.c:3787
> >  ttwu_queue kernel/sched/core.c:4029 [inline]
> >  try_to_wake_up+0x8e7/0x15b0 kernel/sched/core.c:4346
> >  autoremove_wake_function+0x16/0x150 kernel/sched/wait.c:424
> >  __wake_up_common+0x140/0x5a0 kernel/sched/wait.c:107
> >  __wake_up_common_lock+0xd6/0x140 kernel/sched/wait.c:138
> >  wake_up_klogd_work_func kernel/printk/printk.c:3840 [inline]
> >  wake_up_klogd_work_func+0x90/0xa0 kernel/printk/printk.c:3829
> >  irq_work_single+0x1b5/0x260 kernel/irq_work.c:221
> >  irq_work_run_list kernel/irq_work.c:252 [inline]
> >  irq_work_run_list+0x92/0xc0 kernel/irq_work.c:235
> >  update_process_times+0x1d5/0x220 kernel/time/timer.c:2074
> >  tick_sched_handle+0x8e/0x170 kernel/time/tick-sched.c:254
> >  tick_sched_timer+0xe9/0x110 kernel/time/tick-sched.c:1492
> >  __run_hrtimer kernel/time/hrtimer.c:1688 [inline]
> >  __hrtimer_run_queues+0x647/0xc10 kernel/time/hrtimer.c:1752
> >  hrtimer_interrupt+0x31b/0x800 kernel/time/hrtimer.c:1814
> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1063 [inline]
> >  __sysvec_apic_timer_interrupt+0x105/0x3f0 arch/x86/kernel/apic/apic.c:1080
> >  sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1074
> >  </IRQ>