tree 6c5acb1ee8b012d024be4f739b156b28a63fe21f
parent 8980eb0d9001aec10fe4b1a488347431297313f5
author Piotr Krysiuk <piotras@gmail.com> 1617659535 +0100
committer Oleksandr Tymoshenko <ovt@google.com> 1618597868 +0000

bpf, x86: Validate computation of branch displacements for x86-64

commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream.

The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.

But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.

And so the optimizer can expand blocks of machine code in some cases.

This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.

To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.

BUG=b/185462577
TEST=presubmit
RELEASE_NOTE=None

cos-patch: security-high
Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a0b3927a07be0c4cedd69970e082a8c23c92eb72)
Change-Id: Ia132a048f8be915a448b745173f057d2e3a5d187
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/15614
Tested-by: Cusky Presubmit Bot <presubmit@cos-infra-prod.iam.gserviceaccount.com>
Reviewed-by: Robert Kolchmeyer <rkolchmeyer@google.com>