lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAD-N9QWcdR5oxt2JJrEowPwddyNTZVfU5iSOXNV+cTy2+TKnuQ@mail.gmail.com>
Date:   Wed, 13 Jan 2021 17:11:39 +0800
From:   慕冬亮 <mudongliangabcd@...il.com>
To:     andriin@...com, ast@...nel.org, bpf@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>, davem@...emloft.net,
        hawk@...nel.org, john.fastabend@...il.com, kafai@...com,
        kpsingh@...omium.org, kuba@...nel.org,
        linux-kernel <linux-kernel@...r.kernel.org>, mingo@...hat.com,
        netdev@...r.kernel.org, rostedt@...dmis.org, songliubraving@...com,
        yhs@...com, Dmitry Vyukov <dvyukov@...gle.com>
Subject: "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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ