linux-kernel - Re: CVE-2023-52920: bpf: support non-r10 register spill/fill to/from stack in precision tracking

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: <emjjveewgoegvinmjmba4ys34vbmb3sp6r6qefv77i5mtettmj@hsvm5vm3qivd>
Date: Fri, 8 Nov 2024 12:42:54 +0800
From: Shung-Hsi Yu <shung-hsi.yu@...e.com>
To: Andrii Nakryiko <andrii@...nel.org>, 
	Eduard Zingerman <eddyz87@...il.com>, cve@...nel.org
Cc: Tao Lyu <tao.lyu@...l.ch>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org
Subject: Re: CVE-2023-52920: bpf: support non-r10 register spill/fill to/from
 stack in precision tracking

Hi Andrii and Eduard,

I'm trying to determine the security implication of CVE-2023-52920, or
more specifically, what does commit 41f6f64e6999 ("bpf: support non-r10
register spill/fill to/from stack in precision tracking") fix.
Superficially this looks more like an improvement to the verifier.

On Tue, Nov 05, 2024 at 11:09:19AM GMT, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> bpf: support non-r10 register spill/fill to/from stack in precision tracking
...

Before this commit, precise tracking of stack spills/fills was only
supported if the frame pointer register r10 was directly used (and any
offset to the frame pointer had to be presented through insn->off).

In the case where r10 is indirectly used (e.g. using r6 where r6 = r10 -
16), backtrack_insn() would simply return 0, implying that precision
backtracking has completed; which technically isn't correct. However,
since any register that is stored to the stack is already marked as
precise in check_stack_write_fixed_off(), the verifier would not miss
marking registers as precise - it would just be much more conservative
than needed by marking more registers as precise than necessary.

In other words, even without commit 41f6f64e6999, it shouldn't be
possible to craft a BPF program that tricks the verifier into
incorrectly omitting precision marks, as the verifier would err on the
side of being more strict.

Without this commit, the most significant impact would appear to be that
a BPF program could trigger warnings as reported by Tao Lyu[1].

Does that assessment sound correct?

Thanks,
Shung-Hsi Yu

1: https://lore.kernel.org/all/20231020220216.263948-1-tao.lyu@epfl.ch/