Skip to content

Commit 109980b

Browse files
borkmanndavem330
authored andcommitted
bpf: don't select potentially stale ri->map from buggy xdp progs
We can potentially run into a couple of issues with the XDP bpf_redirect_map() helper. The ri->map in the per CPU storage can become stale in several ways, mostly due to misuse, where we can then trigger a use after free on the map: i) prog A is calling bpf_redirect_map(), returning XDP_REDIRECT and running on a driver not supporting XDP_REDIRECT yet. The ri->map on that CPU becomes stale when the XDP program is unloaded on the driver, and a prog B loaded on a different driver which supports XDP_REDIRECT return code. prog B would have to omit calling to bpf_redirect_map() and just return XDP_REDIRECT, which would then access the freed map in xdp_do_redirect() since not cleared for that CPU. ii) prog A is calling bpf_redirect_map(), returning a code other than XDP_REDIRECT. prog A is then detached, which triggers release of the map. prog B is attached which, similarly as in i), would just return XDP_REDIRECT without having called bpf_redirect_map() and thus be accessing the freed map in xdp_do_redirect() since not cleared for that CPU. iii) prog A is attached to generic XDP, calling the bpf_redirect_map() helper and returning XDP_REDIRECT. xdp_do_generic_redirect() is currently not handling ri->map (will be fixed by Jesper), so it's not being reset. Later loading a e.g. native prog B which would, say, call bpf_xdp_redirect() and then returns XDP_REDIRECT would find in xdp_do_redirect() that a map was set and uses that causing use after free on map access. Fix thus needs to avoid accessing stale ri->map pointers, naive way would be to call a BPF function from drivers that just resets it to NULL for all XDP return codes but XDP_REDIRECT and including XDP_REDIRECT for drivers not supporting it yet (and let ri->map being handled in xdp_do_generic_redirect()). There is a less intrusive way w/o letting drivers call a reset for each BPF run. The verifier knows we're calling into bpf_xdp_redirect_map() helper, so it can do a small insn rewrite transparent to the prog itself in the sense that it fills R4 with a pointer to the own bpf_prog. We have that pointer at verification time anyway and R4 is allowed to be used as per calling convention we scratch R0 to R5 anyway, so they become inaccessible and program cannot read them prior to a write. Then, the helper would store the prog pointer in the current CPUs struct redirect_info. Later in xdp_do_*_redirect() we check whether the redirect_info's prog pointer is the same as passed xdp_prog pointer, and if that's the case then all good, since the prog holds a ref on the map anyway, so it is always valid at that point in time and must have a reference count of at least 1. If in the unlikely case they are not equal, it means we got a stale pointer, so we clear and bail out right there. Also do reset map and the owning prog in bpf_xdp_redirect(), so that bpf_xdp_redirect_map() and bpf_xdp_redirect() won't get mixed up, only the last call should take precedence. A tc bpf_redirect() doesn't use map anywhere yet, so no need to clear it there since never accessed in that layer. Note that in case the prog is released, and thus the map as well we're still under RCU read critical section at that time and have preemption disabled as well. Once we commit with the __dev_map_insert_ctx() from xdp_do_redirect_map() and set the map to ri->map_to_flush, we still wait for a xdp_do_flush_map() to finish in devmap dismantle time once flush_needed bit is set, so that is fine. Fixes: 97f91a7 ("bpf: add bpf_redirect_map helper routine") Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent 9a486c9 commit 109980b

File tree

2 files changed

+35
-2
lines changed

2 files changed

+35
-2
lines changed

kernel/bpf/verifier.c

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4203,6 +4203,22 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
42034203
continue;
42044204
}
42054205

4206+
if (insn->imm == BPF_FUNC_redirect_map) {
4207+
u64 addr = (unsigned long)prog;
4208+
struct bpf_insn r4_ld[] = {
4209+
BPF_LD_IMM64(BPF_REG_4, addr),
4210+
*insn,
4211+
};
4212+
cnt = ARRAY_SIZE(r4_ld);
4213+
4214+
new_prog = bpf_patch_insn_data(env, i + delta, r4_ld, cnt);
4215+
if (!new_prog)
4216+
return -ENOMEM;
4217+
4218+
delta += cnt - 1;
4219+
env->prog = prog = new_prog;
4220+
insn = new_prog->insnsi + i + delta;
4221+
}
42064222
patch_call_imm:
42074223
fn = prog->aux->ops->get_func_proto(insn->imm);
42084224
/* all functions that have prototype and verifier allowed

net/core/filter.c

Lines changed: 19 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1794,6 +1794,7 @@ struct redirect_info {
17941794
u32 flags;
17951795
struct bpf_map *map;
17961796
struct bpf_map *map_to_flush;
1797+
const struct bpf_prog *map_owner;
17971798
};
17981799

17991800
static DEFINE_PER_CPU(struct redirect_info, redirect_info);
@@ -1807,7 +1808,6 @@ BPF_CALL_2(bpf_redirect, u32, ifindex, u64, flags)
18071808

18081809
ri->ifindex = ifindex;
18091810
ri->flags = flags;
1810-
ri->map = NULL;
18111811

18121812
return TC_ACT_REDIRECT;
18131813
}
@@ -2504,13 +2504,23 @@ static int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
25042504
struct bpf_prog *xdp_prog)
25052505
{
25062506
struct redirect_info *ri = this_cpu_ptr(&redirect_info);
2507+
const struct bpf_prog *map_owner = ri->map_owner;
25072508
struct bpf_map *map = ri->map;
25082509
u32 index = ri->ifindex;
25092510
struct net_device *fwd;
25102511
int err;
25112512

25122513
ri->ifindex = 0;
25132514
ri->map = NULL;
2515+
ri->map_owner = NULL;
2516+
2517+
/* This is really only caused by a deliberately crappy
2518+
* BPF program, normally we would never hit that case,
2519+
* so no need to inform someone via tracepoints either,
2520+
* just bail out.
2521+
*/
2522+
if (unlikely(map_owner != xdp_prog))
2523+
return -EINVAL;
25142524

25152525
fwd = __dev_map_lookup_elem(map, index);
25162526
if (!fwd) {
@@ -2607,6 +2617,8 @@ BPF_CALL_2(bpf_xdp_redirect, u32, ifindex, u64, flags)
26072617

26082618
ri->ifindex = ifindex;
26092619
ri->flags = flags;
2620+
ri->map = NULL;
2621+
ri->map_owner = NULL;
26102622

26112623
return XDP_REDIRECT;
26122624
}
@@ -2619,7 +2631,8 @@ static const struct bpf_func_proto bpf_xdp_redirect_proto = {
26192631
.arg2_type = ARG_ANYTHING,
26202632
};
26212633

2622-
BPF_CALL_3(bpf_xdp_redirect_map, struct bpf_map *, map, u32, ifindex, u64, flags)
2634+
BPF_CALL_4(bpf_xdp_redirect_map, struct bpf_map *, map, u32, ifindex, u64, flags,
2635+
const struct bpf_prog *, map_owner)
26232636
{
26242637
struct redirect_info *ri = this_cpu_ptr(&redirect_info);
26252638

@@ -2629,10 +2642,14 @@ BPF_CALL_3(bpf_xdp_redirect_map, struct bpf_map *, map, u32, ifindex, u64, flags
26292642
ri->ifindex = ifindex;
26302643
ri->flags = flags;
26312644
ri->map = map;
2645+
ri->map_owner = map_owner;
26322646

26332647
return XDP_REDIRECT;
26342648
}
26352649

2650+
/* Note, arg4 is hidden from users and populated by the verifier
2651+
* with the right pointer.
2652+
*/
26362653
static const struct bpf_func_proto bpf_xdp_redirect_map_proto = {
26372654
.func = bpf_xdp_redirect_map,
26382655
.gpl_only = false,

0 commit comments

Comments
 (0)