linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACkBjsbUytfJS1ns0pp=o=Lk5qbQ5weD4_f8bPFrW5oV0tCXZw@mail.gmail.com>
Date:   Sun, 12 Nov 2023 14:57:38 +0100
From:   Hao Sun <sunhao.th@...il.com>
To:     Andrei Matei <andreimatei1@...il.com>,
        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>
Cc:     bpf <bpf@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: bpf: incorrect stack_depth after var off stack access causes OOB

Hi,

The verifier allows stack access with var off, but the stack depth is
only updated
with `fix` off. For the following program, the verifier incorrectly
marks stack_depth
as 221, yet the smin of r8 is -12 and is overlooked, and thus the interpreter
incorrectly calls `__bpf_prog_run224`, leading to the OOB:

(bf) r6 = r10                      ; R6_w=fp0 R10=fp0
(bc) w8 = w6                       ; R6_w=fp0
R8_w=scalar(smin=0,smax=umax=429496729)
(47) r8 |= -12                     ;
R8_w=scalar(smin=smin32=-12,smax=smax32=-1,umin)
(0f) r8 += r10
(72) *(u8 *)(r8 -221) = -19       ;
R8_w=fp(off=0,smin=smin32=-12,smax=smax32=-1,..
(95) exit

verification time 231 usec
stack depth 221
processed 12 insns (limit 1000000) max_states_per_insn 0 total_states
0 peak_states 0 m0

This C program can cause a stack OOB access:
C Repro: https://pastebin.com/raw/5ReUbCar
OOB: https://pastebin.com/raw/DzVz3NDn

Andrei, you added support for stack access with var off in
`01f810ace9ed3`, in which only
`allocated_stack` is updated, should we also update stack depth?

Best
Hao Sun