bpf: fix incorrect tracking of register size truncation
authorJann Horn <jannh@google.com>
Tue, 19 Dec 2017 04:11:55 +0000 (20:11 -0800)
committerDaniel Borkmann <daniel@iogearbox.net>
Thu, 21 Dec 2017 01:15:41 +0000 (02:15 +0100)
commit0c17d1d2c61936401f4702e1846e2c19b200f958
tree7b91089e5a04b06fb3a6cd3d3939d17f0d5fc0c8
parent95a762e2c8c942780948091f8f2a4f32fce1ac6f
bpf: fix incorrect tracking of register size truncation

Properly handle register truncation to a smaller size.

The old code first mirrors the clearing of the high 32 bits in the bitwise
tristate representation, which is correct. But then, it computes the new
arithmetic bounds as the intersection between the old arithmetic bounds and
the bounds resulting from the bitwise tristate representation. Therefore,
when coerce_reg_to_32() is called on a number with bounds
[0xffff'fff8, 0x1'0000'0007], the verifier computes
[0xffff'fff8, 0xffff'ffff] as bounds of the truncated number.
This is incorrect: The truncated number could also be in the range [0, 7],
and no meaningful arithmetic bounds can be computed in that case apart from
the obvious [0, 0xffff'ffff].

Starting with v4.14, this is exploitable by unprivileged users as long as
the unprivileged_bpf_disabled sysctl isn't set.

Debian assigned CVE-2017-16996 for this issue.

v2:
 - flip the mask during arithmetic bounds calculation (Ben Hutchings)
v3:
 - add CVE number (Ben Hutchings)

Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
kernel/bpf/verifier.c