• T
    bpf: Fix potential race in tail call compatibility check · 54713c85
    Toke Høiland-Jørgensen 提交于
    Lorenzo noticed that the code testing for program type compatibility of
    tail call maps is potentially racy in that two threads could encounter a
    map with an unset type simultaneously and both return true even though they
    are inserting incompatible programs.
    
    The race window is quite small, but artificially enlarging it by adding a
    usleep_range() inside the check in bpf_prog_array_compatible() makes it
    trivial to trigger from userspace with a program that does, essentially:
    
            map_fd = bpf_create_map(BPF_MAP_TYPE_PROG_ARRAY, 4, 4, 2, 0);
            pid = fork();
            if (pid) {
                    key = 0;
                    value = xdp_fd;
            } else {
                    key = 1;
                    value = tc_fd;
            }
            err = bpf_map_update_elem(map_fd, &key, &value, 0);
    
    While the race window is small, it has potentially serious ramifications in
    that triggering it would allow a BPF program to tail call to a program of a
    different type. So let's get rid of it by protecting the update with a
    spinlock. The commit in the Fixes tag is the last commit that touches the
    code in question.
    
    v2:
    - Use a spinlock instead of an atomic variable and cmpxchg() (Alexei)
    v3:
    - Put lock and the members it protects into an embedded 'owner' struct (Daniel)
    
    Fixes: 3324b584 ("ebpf: misc core cleanup")
    Reported-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/bpf/20211026110019.363464-1-toke@redhat.com
    54713c85
bpf.h 69.7 KB