[moderation] [kernel?] BUG: unable to handle kernel paging request in lock_timer_base (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 78d4f34e2115 Linux 6.13-rc3
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=171347e8580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6fe704d2356374ad
dashboard link: https://syzkaller.appspot.com/bug?extid=bf36934adc7979488192
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
CC: [b...@alien8.de dave....@linux.intel.com h...@zytor.com linux-...@vger.kernel.org mi...@redhat.com tg...@linutronix.de x...@kernel.org]

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/01951386840d/disk-78d4f34e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/25dd6cdc37e1/vmlinux-78d4f34e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/76c0990dd6b1/bzImage-78d4f34e.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bf3693...@syzkaller.appspotmail.com

BUG: unable to handle page fault for address: ffffffff9175c704
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD e73a067 P4D e73a067 PUD e73b063 PMD 14d9c9063 PTE 800fffffee8a3062
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 51 Comm: kworker/1:1 Not tainted 6.13.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
Workqueue: rcu_gp process_srcu
RIP: 0010:debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
RIP: 0010:do_raw_spin_lock+0x8b/0x370 kernel/locking/spinlock_debug.c:115
Code: f1 f1 f1 04 f3 f3 f3 48 89 f1 48 89 74 24 38 48 89 04 16 48 8d 5f 04 48 89 d8 48 c1 e8 03 0f b6 04 10 84 c0 0f 85 f6 01 00 00 <8b> 03 3d ad 4e ad de 0f 85 62 01 00 00 4d 8d 6c 24 10 4c 89 e8 48
RSP: 0018:ffffc90000bb77a0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffffff9175c704 RCX: 1ffff92000176efc
RDX: dffffc0000000000 RSI: 1ffff92000176efc RDI: ffffffff9175c700
RBP: ffffc90000bb7870 R08: ffffffff90184ef7 R09: 1ffffffff20309de
R10: dffffc0000000000 R11: fffffbfff20309df R12: ffffffff9175c700
R13: 1ffff92000176f10 R14: ffffffff9175c700 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff9175c704 CR3: 00000000684e8000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:111 [inline]
_raw_spin_lock_irqsave+0xe1/0x120 kernel/locking/spinlock.c:162
lock_timer_base+0x112/0x240 kernel/time/timer.c:1050
__mod_timer+0x1ca/0xeb0 kernel/time/timer.c:1131
srcu_queue_delayed_work_on kernel/rcu/srcutree.c:834 [inline]
srcu_schedule_cbs_sdp kernel/rcu/srcutree.c:843 [inline]
srcu_gp_end kernel/rcu/srcutree.c:910 [inline]
srcu_advance_state kernel/rcu/srcutree.c:1747 [inline]
process_srcu+0x542/0x12e0 kernel/rcu/srcutree.c:1851
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Modules linked in:
CR2: ffffffff9175c704
---[ end trace 0000000000000000 ]---
RIP: 0010:debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
RIP: 0010:do_raw_spin_lock+0x8b/0x370 kernel/locking/spinlock_debug.c:115
Code: f1 f1 f1 04 f3 f3 f3 48 89 f1 48 89 74 24 38 48 89 04 16 48 8d 5f 04 48 89 d8 48 c1 e8 03 0f b6 04 10 84 c0 0f 85 f6 01 00 00 <8b> 03 3d ad 4e ad de 0f 85 62 01 00 00 4d 8d 6c 24 10 4c 89 e8 48
RSP: 0018:ffffc90000bb77a0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffffffff9175c704 RCX: 1ffff92000176efc
RDX: dffffc0000000000 RSI: 1ffff92000176efc RDI: ffffffff9175c700
RBP: ffffc90000bb7870 R08: ffffffff90184ef7 R09: 1ffffffff20309de
R10: dffffc0000000000 R11: fffffbfff20309df R12: ffffffff9175c700
R13: 1ffff92000176f10 R14: ffffffff9175c700 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff9175c704 CR3: 00000000684e8000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: f1 int1
1: f1 int1
2: f1 int1
3: 04 f3 add $0xf3,%al
5: f3 f3 48 89 f1 repz repz mov %rsi,%rcx
a: 48 89 74 24 38 mov %rsi,0x38(%rsp)
f: 48 89 04 16 mov %rax,(%rsi,%rdx,1)
13: 48 8d 5f 04 lea 0x4(%rdi),%rbx
17: 48 89 d8 mov %rbx,%rax
1a: 48 c1 e8 03 shr $0x3,%rax
1e: 0f b6 04 10 movzbl (%rax,%rdx,1),%eax
22: 84 c0 test %al,%al
24: 0f 85 f6 01 00 00 jne 0x220
* 2a: 8b 03 mov (%rbx),%eax <-- trapping instruction
2c: 3d ad 4e ad de cmp $0xdead4ead,%eax
31: 0f 85 62 01 00 00 jne 0x199
37: 4d 8d 6c 24 10 lea 0x10(%r12),%r13
3c: 4c 89 e8 mov %r13,%rax
3f: 48 rex.W


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

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

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

[Matthieu Baerts]

Hello,

It looks like this bug report is linked to the MPTCP subsystem, but I'm not sure why.

In fact, it's not clear to me which one it should be linked to. Maybe RCU? (or another subsystem using RCU?)

#syz set subsystems: rcu

[Aleksandr Nogikh]

Hi Matthieu,

Syzbot attributed it to mctp because of the the second crash report:
https://syzkaller.appspot.com/text?tag=CrashReport&x=124f750f980000

This bug is currently in the moderation stage. Shall we push it to the
public mailing lists?

--
Aleksandr

On Fri, Feb 7, 2025 at 11:13 AM 'Matthieu Baerts' via
syzkaller-upstream-moderation

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-upstream-moderation" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-upstream-m...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-upstream-moderation/e6602851-f471-4f90-a693-2b79ed987311n%40googlegroups.com.

[Matthieu Baerts]

Hi Aleksandr,

Thank you for this reply!

On Friday, February 7, 2025 at 12:19:33 PM UTC+1 Aleksandr Nogikh wrote:

Syzbot attributed it to mctp because of the the second crash report:
https://syzkaller.appspot.com/text?tag=CrashReport&x=124f750f980000

Oh, I missed that, I appreciate the pointer.

The two crash reports seem unrelated. Is it possible to "unlink" them?

The second crash report looks very similar to ...

  https://syzkaller.appspot.com/bug?extid=f3a31fb909db9b2a5c4d

  https://syzkaller.appspot.com/bug?extid=3a98aec25a4ab6a4d963

... which were supposed to be fixed:

  https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b4cd80b03389

Apparently not, or there is something else to fix :)

This bug is currently in the moderation stage. Shall we push it to the
public mailing lists?

Mmh, I guess we can, but I don't really have time to dedicate to that. Once it is pushed to public ML, it feels like we have to rush to look at it :)
Maybe someone else can look at it.

Cheers,

Matt

[Aleksandr Nogikh]

Hi Matt,

On Fri, Feb 7, 2025 at 1:05 PM 'Matthieu Baerts' via
syzkaller-upstream-moderation

<syzkaller-upst...@googlegroups.com> wrote:
>
> Hi Aleksandr,
>
> Thank you for this reply!
>
> On Friday, February 7, 2025 at 12:19:33 PM UTC+1 Aleksandr Nogikh wrote:
>
> Syzbot attributed it to mctp because of the the second crash report:
> https://syzkaller.appspot.com/text?tag=CrashReport&x=124f750f980000
>
>
> Oh, I missed that, I appreciate the pointer.
>
> The two crash reports seem unrelated. Is it possible to "unlink" them?

No, it's unfortunately a bit too problematic to unlink them now.
But we could adjust the report parsing logic so that if those crashes
happen again, they would be attributed to different bugs.

--
Aleksandr

>
> The second crash report looks very similar to ...
>
> https://syzkaller.appspot.com/bug?extid=f3a31fb909db9b2a5c4d
> https://syzkaller.appspot.com/bug?extid=3a98aec25a4ab6a4d963
>
> ... which were supposed to be fixed:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b4cd80b03389
>
> Apparently not, or there is something else to fix :)
>
> This bug is currently in the moderation stage. Shall we push it to the
> public mailing lists?
>
>
> Mmh, I guess we can, but I don't really have time to dedicate to that. Once it is pushed to public ML, it feels like we have to rush to look at it :)
> Maybe someone else can look at it.
>
> Cheers,
> Matt
>

> -

[Matthieu Baerts]

Hi Aleksandr,

On 11/02/2025 11:43, Aleksandr Nogikh wrote:
> Hi Matt,
>
> On Fri, Feb 7, 2025 at 1:05 PM 'Matthieu Baerts' via
> syzkaller-upstream-moderation
> <syzkaller-upst...@googlegroups.com> wrote:
>>
>> Hi Aleksandr,
>>
>> Thank you for this reply!
>>
>> On Friday, February 7, 2025 at 12:19:33 PM UTC+1 Aleksandr Nogikh wrote:
>>
>> Syzbot attributed it to mctp because of the the second crash report:
>> https://syzkaller.appspot.com/text?tag=CrashReport&x=124f750f980000
>>
>>
>> Oh, I missed that, I appreciate the pointer.
>>
>> The two crash reports seem unrelated. Is it possible to "unlink" them?
>
> No, it's unfortunately a bit too problematic to unlink them now.

I understand.

> But we could adjust the report parsing logic so that if those crashes
> happen again, they would be attributed to different bugs.

If it is possible, that would be great if the parsing logic can be
adjusted, to avoid the confusion around the link with MPTCP.

Cheers,
Matt
--
Sponsored by the NGI0 Core fund.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.