linux-kernel - Re: bpf: incorrect stack_depth after var off stack access causes OOB

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACkBjsbxO802EsBWUsGvkV8VPtsRLhRh2rHnGRuy_ziFXj=X0A@mail.gmail.com>
Date:   Tue, 14 Nov 2023 09:34:34 +0100
From:   Hao Sun <sunhao.th@...il.com>
To:     Andrei Matei <andreimatei1@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>,
        Yonghong Song <yonghong.song@...ux.dev>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: bpf: incorrect stack_depth after var off stack access causes OOB

On Tue, Nov 14, 2023 at 1:03 AM Andrei Matei <andreimatei1@...il.com> wrote:
>
> I have sent https://lore.kernel.org/bpf/20231113235008.127238-1-andreimatei1@gmail.com/T/#u
> as a fix.
>
> Hao, thanks again for the report. For my edification, how did you get
> the KASAN bug report with your repro / which tree exactly were you
> running against and with what config? I've run your repro program in
> the VM created by vmtest.sh, with an added CONFIG_KASAN=y in the
> config, and I did not get the bug report in dmesg; I got nothing.
> However, if I change the variable offset bounds to be around 200 bytes
> instead of 12, then I do get a kernel panic because of a page fault.

I guess the key difference is that I do not use JIT (CONFIG_BPF_JIT=n).
With KASAN, the interpreter is instrumented for memory access checking,
but JITed eBPF programs will not, that's why you need to increase the off
to trigger the page fault.

Here is my config: https://pastebin.com/raw/q170XGxd

Also, this bug can be exploited by users with CAP_PERFMON, and kernels
after v5.10.33 are all impacted. So we should CC stable kernel:

Cc: stable@...r.kernel.org