[syzbot] [kernel?] general protection fault in task_work_cancel

2 views
Skip to first unread message

syzbot

unread,
12:17 AM (11 hours ago) 12:17 AM
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: af4e9ef3d784 uaccess: Fix scoped_user_read_access() for 'p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13774952580000
kernel config: https://syzkaller.appspot.com/x/.config?x=779072223d02a312
dashboard link: https://syzkaller.appspot.com/bug?extid=741e2278ef71fef03a10
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f6b75c8f432f/disk-af4e9ef3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4513ad566789/vmlinux-af4e9ef3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f7eea878db42/bzImage-af4e9ef3.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc000000013c: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x00000000000009e0-0x00000000000009e7]
CPU: 1 UID: 0 PID: 8400 Comm: syz.0.629 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:task_work_pending include/linux/task_work.h:26 [inline]
RIP: 0010:task_work_cancel_match kernel/task_work.c:124 [inline]
RIP: 0010:task_work_cancel+0x8a/0x220 kernel/task_work.c:187
Code: b8 f1 f1 f1 f1 f8 f3 f3 f3 4b 89 44 25 00 e8 bd b6 35 00 43 c6 44 25 04 00 49 89 de 48 81 c3 e0 09 00 00 49 89 df 49 c1 ef 03 <43> 80 3c 27 00 74 08 48 89 df e8 17 f5 9f 00 48 83 3b 00 75 51 e8
RSP: 0018:ffffc9001eadfb20 EFLAGS: 00010216
RAX: ffffffff818fdf23 RBX: 00000000000009e0 RCX: 0000000000080000
RDX: ffffc9000e905000 RSI: 00000000000099dd RDI: 00000000000099de
RBP: ffffc9001eadfbd0 R08: ffffc9001eadfc97 R09: 1ffff92003d5bf92
R10: dffffc0000000000 R11: fffff52003d5bf93 R12: dffffc0000000000
R13: 1ffff92003d5bf68 R14: 0000000000000000 R15: 000000000000013c
FS: 00007f83f86a96c0(0000) GS:ffff888125564000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff8027ea4b8 CR3: 0000000021f07000 CR4: 0000000000350ef0
Call Trace:
<TASK>
cancel_tsync_works security/landlock/tsync.c:415 [inline]
landlock_restrict_sibling_threads+0xdc4/0x11f0 security/landlock/tsync.c:533
__do_sys_landlock_restrict_self security/landlock/syscalls.c:574 [inline]
__se_sys_landlock_restrict_self+0x540/0x810 security/landlock/syscalls.c:482
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f83f779c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f83f86a9028 EFLAGS: 00000246 ORIG_RAX: 00000000000001be
RAX: ffffffffffffffda RBX: 00007f83f7a16090 RCX: 00007f83f779c799
RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000004
RBP: 00007f83f7832bd9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f83f7a16128 R14: 00007f83f7a16090 R15: 00007fff928f0338
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:task_work_pending include/linux/task_work.h:26 [inline]
RIP: 0010:task_work_cancel_match kernel/task_work.c:124 [inline]
RIP: 0010:task_work_cancel+0x8a/0x220 kernel/task_work.c:187
Code: b8 f1 f1 f1 f1 f8 f3 f3 f3 4b 89 44 25 00 e8 bd b6 35 00 43 c6 44 25 04 00 49 89 de 48 81 c3 e0 09 00 00 49 89 df 49 c1 ef 03 <43> 80 3c 27 00 74 08 48 89 df e8 17 f5 9f 00 48 83 3b 00 75 51 e8
RSP: 0018:ffffc9001eadfb20 EFLAGS: 00010216
RAX: ffffffff818fdf23 RBX: 00000000000009e0 RCX: 0000000000080000
RDX: ffffc9000e905000 RSI: 00000000000099dd RDI: 00000000000099de
RBP: ffffc9001eadfbd0 R08: ffffc9001eadfc97 R09: 1ffff92003d5bf92
R10: dffffc0000000000 R11: fffff52003d5bf93 R12: dffffc0000000000
R13: 1ffff92003d5bf68 R14: 0000000000000000 R15: 000000000000013c
FS: 00007f83f86a96c0(0000) GS:ffff888125564000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007faa33e5c000 CR3: 0000000021f07000 CR4: 0000000000350ef0
----------------
Code disassembly (best guess):
0: b8 f1 f1 f1 f1 mov $0xf1f1f1f1,%eax
5: f8 clc
6: f3 f3 f3 4b 89 44 25 repz repz xrelease mov %rax,0x0(%r13,%r12,1)
d: 00
e: e8 bd b6 35 00 call 0x35b6d0
13: 43 c6 44 25 04 00 movb $0x0,0x4(%r13,%r12,1)
19: 49 89 de mov %rbx,%r14
1c: 48 81 c3 e0 09 00 00 add $0x9e0,%rbx
23: 49 89 df mov %rbx,%r15
26: 49 c1 ef 03 shr $0x3,%r15
* 2a: 43 80 3c 27 00 cmpb $0x0,(%r15,%r12,1) <-- trapping instruction
2f: 74 08 je 0x39
31: 48 89 df mov %rbx,%rdi
34: e8 17 f5 9f 00 call 0x9ff550
39: 48 83 3b 00 cmpq $0x0,(%rbx)
3d: 75 51 jne 0x90
3f: e8 .byte 0xe8


---
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

Tetsuo Handa

unread,
12:21 AM (11 hours ago) 12:21 AM
to linux-security-module, Günther Noack, syzkall...@googlegroups.com, syzbot
syzbot is reporting NULL pointer dereference at cancel_tsync_works(), for
tsync_works_release() checks for works->works[i]->task != NULL but
cancel_tsync_works() does not.

works->works[i]->task becomes NULL when tsync_works_provide() incremented
works->size and then task_work_add() returned an error. Therefore,
cancel_tsync_works() needs to check for works->works[i]->task != NULL.

Reported-by: syzbot <syzbot+741e22...@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=741e2278ef71fef03a10
Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
Signed-off-by: Tetsuo Handa <penguin...@I-love.SAKURA.ne.jp>
---
security/landlock/tsync.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
index de01aa899751..8925acbef8a5 100644
--- a/security/landlock/tsync.c
+++ b/security/landlock/tsync.c
@@ -412,6 +412,8 @@ static void cancel_tsync_works(struct tsync_works *works,
int i;

for (i = 0; i < works->size; i++) {
+ if (!works->works[i]->task)
+ continue;
if (!task_work_cancel(works->works[i]->task,
&works->works[i]->work))
continue;
--
2.53.0

Mickaël Salaün

unread,
4:01 AM (7 hours ago) 4:01 AM
to Tetsuo Handa, linux-security-module, Günther Noack, syzkall...@googlegroups.com, syzbot
Thanks. This issue was fixed in -next with
https://lore.kernel.org/all/20260217122341...@digikod.net/

I'll send a PR next week.
Reply all
Reply to author
Forward
0 new messages