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.)