]> git.baikalelectronics.ru Git - kernel.git/commit
bpf: Fix pointer arithmetic mask tightening under state pruning
authorDaniel Borkmann <daniel@iogearbox.net>
Fri, 16 Jul 2021 09:18:21 +0000 (09:18 +0000)
committerDaniel Borkmann <daniel@iogearbox.net>
Fri, 16 Jul 2021 14:57:07 +0000 (16:57 +0200)
commit4d137dd71a85eb42eafae83a61dce0e031a72c46
tree10b112f0fcac6f74a221665668a834e6aab04aad
parent17811aa81202c712003bb3ecd9e85ef39deec24f
bpf: Fix pointer arithmetic mask tightening under state pruning

In 430d9c6a851c ("bpf: Tighten speculative pointer arithmetic mask") we
narrowed the offset mask for unprivileged pointer arithmetic in order to
mitigate a corner case where in the speculative domain it is possible to
advance, for example, the map value pointer by up to value_size-1 out-of-
bounds in order to leak kernel memory via side-channel to user space.

The verifier's state pruning for scalars leaves one corner case open
where in the first verification path R_x holds an unknown scalar with an
aux->alu_limit of e.g. 7, and in a second verification path that same
register R_x, here denoted as R_x', holds an unknown scalar which has
tighter bounds and would thus satisfy range_within(R_x, R_x') as well as
tnum_in(R_x, R_x') for state pruning, yielding an aux->alu_limit of 3:
Given the second path fits the register constraints for pruning, the final
generated mask from aux->alu_limit will remain at 7. While technically
not wrong for the non-speculative domain, it would however be possible
to craft similar cases where the mask would be too wide as in 430d9c6a851c.

One way to fix it is to detect the presence of unknown scalar map pointer
arithmetic and force a deeper search on unknown scalars to ensure that
we do not run into a masking mismatch.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
include/linux/bpf_verifier.h
kernel/bpf/verifier.c