How we found and fixed an eBPF Linux kernel vulnerability

  • A reminder that on the platforms eBPF is most commonly used, verifier bugs don't matter much, because unprivileged code isn't allowed to load eBPF programs to begin with. Bugs like this are thus root -> ring0 vulnerabilities. That's not nothing, but for serverside work it's usually worth the tradeoff, especially because eBPF's track record for kernel LPEs is actually pretty strong compared to the kernel as a whole.

    In the setting eBPF is used today, most of the value of the verifier is that it's hard to accidentally crash your kernel with a bad eBPF program. That is comically untrue about an ordinary LKM.

  • > “Uno no es ninguno” (One is none)

    Literally "One not is none", aka "One is not none".

  • The one time I tried to use eBPF it wasn't expressive enough for what I needed.

    Does the limited flexibility it provides really justify the added kernel space complexity? I can understand it for packet filtering but some of the other stuff it's used for like sandboxing just isn't convincing.

  • > “Uno no es ninguno” (One is none)

    I believe that translates to "One is not none"

    https://bughunters.google.com/blog/6303226026131456/a-deep-d...

  • [flagged]

  • In my country we have a saying. "Porcupine in the pants". Sounds like for all the good it can do, it isn't written safely and carefully.