On Sun, 2024-08-11 at 22:21 -0700, Yonghong Song wrote:
> Daniel Hodges reported a kernel verifier crash when playing with sched-ext.
> The crash dump looks like below:
>
> [ 65.874474] BUG: kernel NULL pointer dereference, address: 0000000000000088
> [ 65.888406] #PF: supervisor read access in kernel mode
> [ 65.898682] #PF: error_code(0x0000) - not-present page
> [ 65.908957] PGD 0 P4D 0
> [ 65.914020] Oops: 0000 [#1] SMP
> [ 65.920300] CPU: 19 PID: 9364 Comm: scx_layered Kdump: loaded Tainted: G S E 6.9.5-g93cea04637ea-dirty #7
> [ 65.941874] Hardware name: Quanta Delta Lake MP 29F0EMA01D0/Delta Lake-Class1, BIOS F0E_3A19 04/27/2023
> [ 65.960664] RIP: 0010:states_equal+0x3ee/0x770
> [ 65.969559] Code: 33 85 ed 89 e8 41 0f 48 c7 83 e0 f8 89 e9 29 c1 48 63 c1 4c 89 e9 48 c1 e1 07 49 8d 14 08 0f
> b6 54 10 78 49 03 8a 58 05 00 00 <3a> 54 08 78 0f 85 60 03 00 00 49 c1 e5 07 43 8b 44 28 70 83 e0 03
> [ 66.007120] RSP: 0018:ffffc9000ebeb8b8 EFLAGS: 00010202
> [ 66.017570] RAX: 0000000000000000 RBX: ffff888149719680 RCX: 0000000000000010
> [ 66.031843] RDX: 0000000000000000 RSI: ffff88907f4e0c08 RDI: ffff8881572f0000
> [ 66.046115] RBP: 0000000000000000 R08: ffff8883d5014000 R09: ffffffff83065d50
> [ 66.060386] R10: ffff8881bf9a1800 R11: 0000000000000002 R12: 0000000000000000
> [ 66.074659] R13: 0000000000000000 R14: ffff888149719a40 R15: 0000000000000007
> [ 66.088932] FS: 00007f5d5da96800(0000) GS:ffff88907f4c0000(0000) knlGS:0000000000000000
> [ 66.105114] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 66.116606] CR2: 0000000000000088 CR3: 0000000388261001 CR4: 00000000007706f0
> [ 66.130873] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 66.145145] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 66.159416] PKRU: 55555554
> [ 66.164823] Call Trace:
> [ 66.169709] <TASK>
> [ 66.173906] ? __die_body+0x66/0xb0
> [ 66.180890] ? page_fault_oops+0x370/0x3d0
> [ 66.189082] ? console_unlock+0xb5/0x140
> [ 66.196926] ? exc_page_fault+0x4f/0xb0
> [ 66.204597] ? asm_exc_page_fault+0x22/0x30
> [ 66.212974] ? states_equal+0x3ee/0x770
> [ 66.220643] ? states_equal+0x529/0x770
> [ 66.228312] do_check+0x60f/0x5240
> [ 66.235114] do_check_common+0x388/0x840
> [ 66.242960] do_check_subprogs+0x101/0x150
> [ 66.251150] bpf_check+0x5d5/0x4b60
> [ 66.258134] ? __mod_memcg_state+0x79/0x110
> [ 66.266506] ? pcpu_alloc+0x892/0xba0
> [ 66.273829] bpf_prog_load+0x5bb/0x660
> [ 66.281324] ? bpf_prog_bind_map+0x1e1/0x290
> [ 66.289862] __sys_bpf+0x29d/0x3a0
> [ 66.296664] __x64_sys_bpf+0x18/0x20
> [ 66.303811] do_syscall_64+0x6a/0x140
> [ 66.311133] entry_SYSCALL_64_after_hwframe+0x4b/0x53
>
> Forther investigation shows that the crash is due to invalid memory access in stacksafe().
> More specifically, it is the following code:
>
> if (exact != NOT_EXACT &&
> old->stack[spi].slot_type[i % BPF_REG_SIZE] !=
> cur->stack[spi].slot_type[i % BPF_REG_SIZE])
> return false;
>
> If cur->allocated_stack is 0, cur->stack will be a ZERO_SIZE_PTR. If this happens,
> cur->stack[spi].slot_type[i % BPF_REG_SIZE] will crash the kernel as the memory
> address is illegal. This is exactly what happened in the above crash dump.
> If cur->allocated_stack is not 0, the above code could trigger array out-of-bound
> access.
>
> The patch added a condition 'i < cur->allocated_stack' to ensure
> cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access always legal.
>
> Fixes: 2793a8b015f7 ("bpf: exact states comparison for iterator convergence checks")
> Cc: Eduard Zingerman <eddyz87@xxxxxxxxx>
> Reported-by: Daniel Hodges <hodgesd@xxxxxxxx>
> Signed-off-by: Yonghong Song <yonghong.song@xxxxxxxxx>
> ---
My bad, for some reason I thought that 'if (i >= cur->allocated_stack) return false;'
check below would be sufficient. (Which is obviously not true, sigh...).
Acked-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
[...]
