In late March, there was a Linux kernel security issue, CVE-2020-8835 ( also ). This was, to quote the Ubuntu CVE description:

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 bpf(2) manpage says ; per the exploit writeup , 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.)