BUG: KASAN: vmalloc-out-of-bounds in memset32 (bpf_prog_pack_free)

[Benjamin Gray]

On Wed, 2024-01-31 at 11:46 +0000, Christophe Leroy wrote:
> Hi,
> 
> Got the following BUG while loading module test_bpf.ko
> 
> No time to investigate for now.
> 
> root at vgoip:~# insmod test_bpf.ko
> [  263.409030] 
> ==================================================================
> [  263.416415] BUG: KASAN: vmalloc-out-of-bounds in
> memset32+0x5c/0xa0
> [  263.422952] Write of size 4 at addr c9000e40 by task kworker/0:0/7
> [  263.429322]
> [  263.430816] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 
> 6.8.0-rc1-s3k-dev-02364-gc626219462a6-dirty #606
> [  263.440580] Hardware name: MIAE 8xx 0x500000 CMPC885
> [  263.445658] Workqueue: events bpf_prog_free_deferred
> [  263.450973] Call Trace:
> [  263.453411] [c905bd00] [c0c114e8] dump_stack_lvl+0x34/0x50
> (unreliable)
> [  263.460744] [c905bd20] [c026b9d4] print_report+0x174/0x608
> [  263.466853] [c905bd70] [c026c01c] kasan_report+0xc0/0x130
> [  263.472788] [c905bdd0] [c0c43cb0] memset32+0x5c/0xa0
> [  263.478198] [c905bdf0] [c0030690] patch_instructions+0x70/0x17c
> [  263.484656] [c905be30] [c00389b0]
> bpf_arch_text_invalidate+0xa8/0x120
> [  263.491638] [c905be90] [c018e63c] bpf_prog_pack_free+0xec/0x24c
> [  263.498096] [c905bec0] [c018ea34]
> bpf_jit_binary_pack_free+0x3c/0x80
> [  263.504991] [c905bee0] [c0038ae8] bpf_jit_free+0xc0/0x128
> [  263.510925] [c905bf00] [c00790f8] process_one_work+0x310/0x6e8
> [  263.517209] [c905bf50] [c0079b2c] worker_thread+0x65c/0x868
> [  263.523232] [c905bfc0] [c0084b78] kthread+0x17c/0x1ac
> [  263.528817] [c905bff0] [c00181fc] start_kernel_thread+0x10/0x14
> [  263.535279]
> [  263.536782] The buggy address belongs to the virtual mapping at
> [  263.536782]  [c9000000, c9008000) created by:
> [  263.536782]  text_area_cpu_up+0x28/0x1d4
> [  263.551418]
> [  263.552902] The buggy address belongs to the physical page:
> [  263.560228]
> [  263.561713] Memory state around the buggy address:
> [  263.566585]  c9000d00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8
> [  263.573307]  c9000d80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8
> [  263.580027] >c9000e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8
> [  263.586677]                                    ^
> [  263.591370]  c9000e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8
> [  263.598093]  c9000f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8
> [  263.604743] 
> ==================================================================
> 
> Christophe
> 

Looks like a false positive. It's clearly in range of the poking
allocation after all. KASAN apparently leaves VM_ALLOC areas as
poisoned, expecting some kind of subsequent allocator to come and
unpoison specific parts. Except we call map_patch_area() instead of
whatever path generic code was expecting, so we never unpoison the
range. The issue would be pre-existing from the beginning, and gone
unnoticed because the original code path that does the patching (i.e.,
actually interacts with the poking page) isn't instrumented.