Re: [syzbot] [cgroups?] general protection fault in rebuild_sched_domains_locked
From: Chen Ridong
Date: Tue Feb 24 2026 - 01:58:04 EST
On 2026/2/24 13:37, Waiman Long wrote:
> On 2/23/26 11:03 PM, Chen Ridong wrote:
>>
>> On 2026/2/16 13:57, Waiman Long wrote:
>>> On 2/15/26 4:05 PM, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit: 37a93dd5c49b Merge tag 'net-next-7.0' of git://git.kernel...
>>>> git tree: upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1649d073980000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=a512b4a06724b76a
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=460792609a79c085f79f
>>>> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for
>>>> Debian) 2.44
>>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=152086e6580000
>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=139c2eef980000
>>>>
>>>> Downloadable assets:
>>>> disk image:
>>>> https://storage.googleapis.com/syzbot-assets/0dedaafff2ad/disk-37a93dd5.raw.xz
>>>> vmlinux:
>>>> https://storage.googleapis.com/syzbot-assets/aa7fae081497/vmlinux-37a93dd5.xz
>>>> kernel image:
>>>> https://storage.googleapis.com/syzbot-assets/9096b39b53e1/bzImage-37a93dd5.xz
>>>>
>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>> Reported-by: syzbot+460792609a79c085f79f@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
>>>> R13: 00007fe00de15fac R14: 00007fe00de15fa0 R15: 00007fe00de15fa0
>>>> </TASK>
>>>> Oops: general protection fault, probably for non-canonical address
>>>> 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
>>>> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
>>>> CPU: 1 UID: 0 PID: 5994 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
>>>> 01/24/2026
>>>> RIP: 0010:bitmap_subset include/linux/bitmap.h:433 [inline]
>>>> RIP: 0010:cpumask_subset include/linux/cpumask.h:836 [inline]
>>>> RIP: 0010:rebuild_sched_domains_locked+0x2aa/0x980 kernel/cgroup/cpuset.c:967
>>>> Code: 7d 05 00 41 83 c4 01 89 de 48 83 c5 08 44 89 e7 e8 fb 76 05 00 41 39 dc
>>>> 0f 8d 4c 04 00 00 e8 fd 7c 05 00 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 0f 85
>>>> 1d 06 00 00 48 8b 04 24 48 23 45 00 31 ff 44
>>>> RSP: 0018:ffffc90003ecfbc0 EFLAGS: 00010246
>>>> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000020
>>>> RDX: ffff888028de0000 RSI: ffffffff8200f003 RDI: ffffffff8df14f28
>>>> RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff
>>>> R10: ffffffff8e7d95b3 R11: 0000000000000001 R12: 0000000000000000
>>>> R13: 00000000000f4240 R14: dffffc0000000000 R15: 0000000000000000
>>>> FS: 000055555c694500(0000) GS:ffff8881246a5000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 0000001b2f463fff CR3: 000000003704c000 CR4: 00000000003526f0
>>>> Call Trace:
>>>> <TASK>
>>>> rebuild_sched_domains_cpuslocked kernel/cgroup/cpuset.c:983 [inline]
>>>> rebuild_sched_domains+0x21/0x40 kernel/cgroup/cpuset.c:990
>>>> sched_rt_handler+0xb5/0xe0 kernel/sched/rt.c:2911
>>>> proc_sys_call_handler+0x47f/0x5a0 fs/proc/proc_sysctl.c:600
>>>> new_sync_write fs/read_write.c:595 [inline]
>>>> vfs_write+0x6ac/0x1070 fs/read_write.c:688
>>>> ksys_write+0x12a/0x250 fs/read_write.c:740
>>>> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>>>> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
>>>> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>> RIP: 0033:0x7fe00db9bf79
>>>> 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:00007fff27bcda88 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>> RAX: ffffffffffffffda RBX: 00007fe00de15fa0 RCX: 00007fe00db9bf79
>>>> RDX: 00000000000000f6 RSI: 0000200000000000 RDI: 0000000000000003
>>>> RBP: 00007fff27bcdaf0 R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
>>>> R13: 00007fe00de15fac R14: 00007fe00de15fa0 R15: 00007fe00de15fa0
>>>> </TASK>
>>>> Modules linked in:
>>>> ---[ end trace 0000000000000000 ]---
>>>> RIP: 0010:bitmap_subset include/linux/bitmap.h:433 [inline]
>>>> RIP: 0010:cpumask_subset include/linux/cpumask.h:836 [inline]
>>>> RIP: 0010:rebuild_sched_domains_locked+0x2aa/0x980 kernel/cgroup/cpuset.c:967
>>>> Code: 7d 05 00 41 83 c4 01 89 de 48 83 c5 08 44 89 e7 e8 fb 76 05 00 41 39 dc
>>>> 0f 8d 4c 04 00 00 e8 fd 7c 05 00 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 0f 85
>>>> 1d 06 00 00 48 8b 04 24 48 23 45 00 31 ff 44
>>>> RSP: 0018:ffffc90003ecfbc0 EFLAGS: 00010246
>>>> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000020
>>>> RDX: ffff888028de0000 RSI: ffffffff8200f003 RDI: ffffffff8df14f28
>>>> RBP: 0000000000000000 R08: 0000000000000cc0 R09: 00000000ffffffff
>>>> R10: ffffffff8e7d95b3 R11: 0000000000000001 R12: 0000000000000000
>>>> R13: 00000000000f4240 R14: dffffc0000000000 R15: 0000000000000000
>>>> FS: 000055555c694500(0000) GS:ffff8881246a5000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 0000001b2f463fff CR3: 000000003704c000 CR4: 00000000003526f0
>>>> ----------------
>>>> Code disassembly (best guess), 1 bytes skipped:
>>>> 0: 05 00 41 83 c4 add $0xc4834100,%eax
>>>> 5: 01 89 de 48 83 c5 add %ecx,-0x3a7cb722(%rcx)
>>>> b: 08 44 89 e7 or %al,-0x19(%rcx,%rcx,4)
>>>> f: e8 fb 76 05 00 call 0x5770f
>>>> 14: 41 39 dc cmp %ebx,%r12d
>>>> 17: 0f 8d 4c 04 00 00 jge 0x469
>>>> 1d: e8 fd 7c 05 00 call 0x57d1f
>>>> 22: 48 89 e8 mov %rbp,%rax
>>>> 25: 48 c1 e8 03 shr $0x3,%rax
>>>> * 29: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping
>>>> instruction
>>>> 2e: 0f 85 1d 06 00 00 jne 0x651
>>>> 34: 48 8b 04 24 mov (%rsp),%rax
>>>> 38: 48 23 45 00 and 0x0(%rbp),%rax
>>>> 3c: 31 ff xor %edi,%edi
>>>> 3e: 44 rex.R
>>> The cpuset.c:967 is:
>>>
>>> 966 for (i = 0; i < ndoms; ++i) {
>>> 967 if (WARN_ON_ONCE(!cpumask_subset(doms[i],
>>> cpu_active_mask)))
>>> 968 return;
>>>
>>> The oops was caused by accessing doms[i] which was kmalloc'ed in
>>> generate_sched_domains() by calling alloc_sched_domains() in
>>> kernel/sched/topology.c. Looking at the console log just before the oops, I saw
>>>
>>> [ 124.398850][ T5994] FAULT_INJECTION: forcing a failure.
>>> [ 124.398850][ T5994] name failslab, interval 1, probability 0, space 0,
>>> times 1
>>> [ 124.434865][ T5994] CPU: 1 UID: 0 PID: 5994 Comm: syz.0.17 Not tainted
>>> syzkaller #0 PREEMPT(full)
>>> [ 124.434909][ T5994] Hardware name: Google Google Compute Engine/Google
>>> Compute Engine, BIOS Google 01/24/2026
>>> [ 124.434936][ T5994] Call Trace:
>>> [ 124.434947][ T5994] <TASK>
>>> [ 124.434959][ T5994] dump_stack_lvl+0x100/0x190
>>> [ 124.435026][ T5994] should_fail_ex.cold+0x5/0xa
>>> [ 124.435062][ T5994] ? rebuild_sched_domains_locked+0x51/0x980
>>> [ 124.435113][ T5994] should_failslab+0xc2/0x120
>>> [ 124.435153][ T5994] __kmalloc_noprof+0xe0/0x850
>>> [ 124.435195][ T5994] rebuild_sched_domains_locked+0x51/0x980
>>> [ 124.435266][ T5994] rebuild_sched_domains+0x21/0x40
>>> [ 124.435314][ T5994] sched_rt_handler+0xb5/0xe0
>>> [ 124.435359][ T5994] proc_sys_call_handler+0x47f/0x5a0
>>> [ 124.435413][ T5994] ? __pfx_proc_sys_call_handler+0x10/0x10
>>> [ 124.435475][ T5994] vfs_write+0x6ac/0x1070
>>> [ 124.435511][ T5994] ? __pfx_proc_sys_write+0x10/0x10
>>> [ 124.435562][ T5994] ? __pfx_vfs_write+0x10/0x10
>>> [ 124.435597][ T5994] ? __pfx_do_sys_openat2+0x10/0x10
>>> [ 124.435664][ T5994] ksys_write+0x12a/0x250
>>> [ 124.435696][ T5994] ? __pfx_ksys_write+0x10/0x10
>>> [ 124.435730][ T5994] ? do_user_addr_fault+0x8d6/0x12f0
>>> [ 124.435787][ T5994] do_syscall_64+0x106/0xf80
>>> [ 124.435834][ T5994] ? clear_bhb_loop+0x40/0x90
>>> [ 124.435875][ T5994] entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>
>>> So it looks like the oops may be expected. It may not be a bug in the cpuset
>>> AFAICS.
>>>
>> Hi Longman,
>>
>> Thank you for looking into this issue.
>>
>> Since partition_sched_domains_locked can handle the situation where 'doms' is
>> NULL, I think we should make it robust and fix it.
>>
>> The fix can be implemented as follows:
>>
>> In cpuset.c at line 964:
>>
>> for (i = 0; i < ndoms; ++i) {
>> - if (WARN_ON_ONCE(!cpumask_subset(doms[i], cpu_active_mask)))
>> + if (doms && WARN_ON_ONCE(!cpumask_subset(doms[i],
>> + cpu_active_mask)))
>> return;
>> }
>>
> The problem is that doms is not NULL. It is 0xdffffc0000000000 as shown in the
> dmesg log. So the null check here won't do any good in this particular case. In
> fact, there is already a null check right after alloc_sched_domains() above.
>
Looking at the dmesg log:
[ 124.660383][ T5994] Oops: general protection fault, probably for
non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
[ 124.672366][ T5994] KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007]
The address 0xdffffc0000000000 appears to be the KASAN shadow offset, which is
configured in:
arch/x86/Kconfig:413
config KASAN_SHADOW_OFFSET
hex
depends on KASAN
default 0xdffffc0000000000
This indicates that doms is actually NULL. In generate_sched_domains(), doms is
first assigned to NULL.
Indeed, there is already a NULL check right after alloc_sched_domains(), when
doms is NULL, it returns ndoms = 1 and doms = NULL. Therefore, I believe we need
to add 'doms' check in the rebuild_sched_domains_locked.
--
Best regards,
Ridong