Hello,
syzbot found the following issue on:
HEAD commit: 6a8f57ae2eb0 Linux 6.3-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154fe6c0280000
kernel config: https://syzkaller.appspot.com/x/.config?x=fa4baf7c6b35b5d5
dashboard link: https://syzkaller.appspot.com/bug?extid=5c54bd3eb218bb595aa9
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/fd87c4c006cf/disk-6a8f57ae.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2ac4347e9165/vmlinux-6a8f57ae.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e5844a1e58ba/bzImage-6a8f57ae.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
==================================================================
BUG: KCSAN: data-race in do_timer_create / do_timer_create
write to 0xffff888100ea9bc4 of 4 bytes by task 7660 on cpu 1:
do_timer_create+0x2fd/0xa30 kernel/time/posix-timers.c:516
__se_sys_timer_create kernel/time/posix-timers.c:577 [inline]
__x64_sys_timer_create+0xbb/0xe0 kernel/time/posix-timers.c:577
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffff888100ea9bc4 of 4 bytes by task 7659 on cpu 0:
posix_timer_add kernel/time/posix-timers.c:143 [inline]
do_timer_create+0x19f/0xa30 kernel/time/posix-timers.c:516
__se_sys_timer_create kernel/time/posix-timers.c:577 [inline]
__x64_sys_timer_create+0xbb/0xe0 kernel/time/posix-timers.c:577
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x00000018 -> 0x00000026
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 7659 Comm: syz-executor.1 Not tainted 6.3.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
==================================================================
---
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 [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Fri, 21 Apr 2023 at 16:34, syzbot
<[email protected]> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 6a8f57ae2eb0 Linux 6.3-rc7
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=154fe6c0280000
> kernel config: https://syzkaller.appspot.com/x/.config?x=fa4baf7c6b35b5d5
> dashboard link: https://syzkaller.appspot.com/bug?extid=5c54bd3eb218bb595aa9
> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/fd87c4c006cf/disk-6a8f57ae.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/2ac4347e9165/vmlinux-6a8f57ae.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/e5844a1e58ba/bzImage-6a8f57ae.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
Here this:
int first_free_id = sig->posix_timer_id;
runs concurrently with:
if (++sig->posix_timer_id < 0)
sig->posix_timer_id = 0;
if ((sig->posix_timer_id == first_free_id) && (ret == -ENOENT))
/* Loop over all possible ids completed */
ret = -EAGAIN;
I am not sure how important/realistic this wrap-around handling is,
but as the result of the race first_free_id can be negative (if it
reads the value at just the right moment). Then wrap-around will never
be detected and the loop will loop forever uninterruptably.
> ==================================================================
> BUG: KCSAN: data-race in do_timer_create / do_timer_create
>
> write to 0xffff888100ea9bc4 of 4 bytes by task 7660 on cpu 1:
> do_timer_create+0x2fd/0xa30 kernel/time/posix-timers.c:516
> __se_sys_timer_create kernel/time/posix-timers.c:577 [inline]
> __x64_sys_timer_create+0xbb/0xe0 kernel/time/posix-timers.c:577
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> read to 0xffff888100ea9bc4 of 4 bytes by task 7659 on cpu 0:
> posix_timer_add kernel/time/posix-timers.c:143 [inline]
> do_timer_create+0x19f/0xa30 kernel/time/posix-timers.c:516
> __se_sys_timer_create kernel/time/posix-timers.c:577 [inline]
> __x64_sys_timer_create+0xbb/0xe0 kernel/time/posix-timers.c:577
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> value changed: 0x00000018 -> 0x00000026
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 0 PID: 7659 Comm: syz-executor.1 Not tainted 6.3.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
> ==================================================================
> ---
> 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 [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Fri, Apr 21 2023 at 16:49, Dmitry Vyukov wrote:
> int first_free_id = sig->posix_timer_id;
>
> runs concurrently with:
>
> if (++sig->posix_timer_id < 0)
> sig->posix_timer_id = 0;
> if ((sig->posix_timer_id == first_free_id) && (ret == -ENOENT))
> /* Loop over all possible ids completed */
> ret = -EAGAIN;
>
> I am not sure how important/realistic this wrap-around handling is,
> but as the result of the race first_free_id can be negative (if it
> reads the value at just the right moment). Then wrap-around will never
> be detected and the loop will loop forever uninterruptably.
It's probably not that problematic, but that code is silly for other
reasons. I'll have a look.
Thanks,
tglx