We've disabled eBPF for normal users on our Linux machines
In the Linux kernel 5.5.0 and newer, the bpf verifier (kernel/bpf/verifier.c) did not properly restrict the register bounds for 32-bit operations, leading to out-of-bounds reads and writes in kernel memory. The vulnerability also affects the Linux 5.4 stable series, starting with v5.4.7, [...]
We were lucky. Because we run the standard Ubuntu 18.04 server kernels instead of the HWE kernels, we were not affected by this and did not have to go through a fleet wide kernel update and reboot while working from home.
You might wonder why an issue in eBPF
creates a security vulnerability, as I did at the time. The answer
is that these days, eBPF programs can be used by ordinary users on
their own sockets (contrary to what the current
says; per the
this was a change added in kernel 4.4). This means that bugs in the
eBPF verifier and JIT translation that allow bad stuff to slip
through are fatal; the entire system's security rests on them being
completely right all of the time.
Fortunately there is a kernel sysctl that controls whether normal users can use eBPF, kernel.unprivileged_bpf_disabled; if set to '1', normal users can't use eBPF. You can probably guess what we immediately did when this CVE came out, even though it didn't apply to us; we immediately pushed out a local update to all of our machines that turned this on, disabling user eBPF programs. Much like user namespaces (which kept enabling kernel security issues) and overlayfs, we feel that allowing user eBPF programs is too much risk right now for too little potential gain. Perhaps someday there will be a compelling usage for this, but for now we'd rather avoid a whole class of potential security issues.
(If anything has broken as a result of this, people haven't told us.)