]> 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)
commite042aa532c84d18ff13291d00620502ce7a38dda
tree10b112f0fcac6f74a221665668a834e6aab04aad
parent59089a189e3adde4cf85f2ce479738d1ae4c514d
bpf: Fix pointer arithmetic mask tightening under state pruning

In 7fedb63a8307 ("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 7fedb63a8307.

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