from Hacker News

How we found and fixed an eBPF Linux kernel vulnerability

by xxmarkuski on 8/8/24, 10:39 AM with 65 comments

  • by tptacek on 8/8/24, 2:37 PM

    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.

  • by TacticalCoder on 8/8/24, 9:00 PM

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

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

  • by katzinsky on 8/8/24, 1:16 PM

    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.

  • by mrbluecoat on 8/8/24, 2:42 PM

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

  • by techwiz137 on 8/8/24, 2:13 PM

    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.