"KASAN: vmalloc-out-of-bounds Read in bpf_trace_run1/2/3/5" and "BUG: unable to handle kernel paging request in bpf_trace_run1/2/3/4" should share the same root cause

* "KASAN: vmalloc-out-of-bounds Read in bpf_trace_run1/2/3/5" and "BUG: unable to handle kernel paging request in bpf_trace_run1/2/3/4" should share the same root cause
@ 2021-01-13  9:11 慕冬亮
  0 siblings, 0 replies; only message in thread
From: 慕冬亮 @ 2021-01-13  9:11 UTC (permalink / raw)
  To: andriin, ast, bpf, Daniel Borkmann, davem, hawk, john.fastabend,
	kafai, kpsingh, kuba, linux-kernel, mingo, netdev, rostedt,
	songliubraving, yhs, Dmitry Vyukov

Hi developers,

I found the following cases should share the same root cause:

BUG: unable to handle kernel paging request in bpf_trace_run1
BUG: unable to handle kernel paging request in bpf_trace_run2
BUG: unable to handle kernel paging request in bpf_trace_run3
BUG: unable to handle kernel paging request in bpf_trace_run4
KASAN: vmalloc-out-of-bounds Read in bpf_trace_run1
KASAN: vmalloc-out-of-bounds Read in bpf_trace_run2
KASAN: vmalloc-out-of-bounds Read in bpf_trace_run3
KASAN: vmalloc-out-of-bounds Read in bpf_trace_run5

The PoCs after minimization are almost the same except for the
different tracepoint arguments.
And the difference for "bpf_trace_run1/2/3/4/5" is due to the
corresponding tracepoints -
"ext4_mballoc_alloc"/"sys_enter"/"sched_switch"/"ext4_ext_show_extent"/"ext4_journal_start".

The underlying reason for those cases is the allocation failure in the
following trace:

tracepoint_probe_unregister
    tracepoint_remove_func
        func_remove
             allocate_probes
                 kmalloc

--
My best regards to you.

     No System Is Safe!
     Dongliang Mu

^ permalink raw reply	[flat|nested] only message in thread