bpf: generalize MAYBE_NULL vs non-MAYBE_NULL rule
authorAndrii Nakryiko <andrii@kernel.org>
Fri, 23 Dec 2022 05:49:17 +0000 (21:49 -0800)
committerAlexei Starovoitov <ast@kernel.org>
Wed, 28 Dec 2022 01:37:07 +0000 (17:37 -0800)
commit7f4ce97cd5edf723c7f2e32668481b6aa86c9ec6
treeab968ca0c33c37fe972902980c5eec0647f3d16d
parenta73bf9f2d969cbb04d5ca778f2a224060cda1027
bpf: generalize MAYBE_NULL vs non-MAYBE_NULL rule

Make generic check to prevent XXX_OR_NULL and XXX register types to be
intermixed. While technically in some situations it could be safe, it's
impossible to enforce due to the loss of an ID when converting
XXX_OR_NULL to its non-NULL variant. So prevent this in general, not
just for PTR_TO_MAP_KEY and PTR_TO_MAP_VALUE.

PTR_TO_MAP_KEY_OR_NULL and PTR_TO_MAP_VALUE_OR_NULL checks, which were
previously special-cased, are simplified to generic check that takes
into account range_within() and tnum_in(). This is correct as BPF
verifier doesn't allow arithmetic on XXX_OR_NULL register types, so
var_off and ranges should stay zero. But even if in the future this
restriction is lifted, it's even more important to enforce that var_off
and ranges are compatible, otherwise it's possible to construct case
where this can be exploited to bypass verifier's memory range safety
checks.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20221223054921.958283-4-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
kernel/bpf/verifier.c