CrowdStrike's Falcon Sensor also linked to Linux kernel panics and crashes

(www.theregister.com)

158 points kenjackson | 1 comments | 22 Jul 24 02:22 UTC | HN request time: 0.001s | source

Show context

roblabla ◴[22 Jul 24 07:17 UTC] No.41031699[source]▶

This is some very poor journalism. The linux issues are so, so very different from the windows BSOD issue.

The redhat kernel panics were caused by a bug in the kernel ebpf implementation, likely a regression introduced by a rhel-specific patch. Blaming crowdstrike for this is stupid (just like blaming microsoft for the crowdstrike bsod is stupid).

For background, I also work on a product using eBPFs, and had kernel updates cause kernel panics in my eBPF probes.

In my case, the panic happened because the kernel decided to change an LSM hook interface, adding a new argument in front of the others. When the probe gets loaded, the kernel doesn’t typecheck the arguments, and so doesn’t realise the probe isn’t compatible with the new kernel. When the probe runs, shit happens and you end up with a kernel panic.

eBPF probes causing kernel panics are almost always indication of a kernel bug, not a bug in the ebpf vendor. There are exceptions of course (such as an ebpf denying access to a resource causing pid1 to crash). But they’re very few.

replies(4): >>41031896 #>>41032164 #>>41032610 #>>41034621 #

watt ◴[22 Jul 24 09:59 UTC] No.41032610[source]▶

>>41031699 #

There should not be any software caused crashes during operation of software. Every NPE that is not caused by hardware issue, is a null pointer not properly handled. Software needs to handle their null checks. Missing a check (or precondition, or validation) is squarely on Microsoft.

> always indication of a kernel bug and before

but:

> blaming microsoft for the crowdstrike bsod is stupid

and who owns the kernel in windows land? Microsoft. how is it stupid to blame Microsoft for not making kernel safe?

replies(3): >>41032783 #>>41032802 #>>41033041 #

1. mebeim ◴[22 Jul 24 10:27 UTC] No.41032802[source]▶

>>41032610 #

Let me give you an analogy: Volvo is known to manufacture very safe cars. Now let's say I drive a Volvo car with a box of dynamite on the passenger seat. I stop at a red light but hit the brake a bit too hard and the box of dynamite falls and causes an explosion, disintegrating everything in a 20-foot radius. So whose fault was it? Volvo?

> Missing a check (or precondition, or validation) is squarely on Microsoft.

Missing a check for presence of dynamite before allowing me to start the car is squarely on Volvo!

You see how silly that sounds?

Now, back to being serious: MS cannot possibly control and validate everything you decide to install and run on your system, specially if the things you install are kernel drivers. It is simply impossible. If you install a kernel driver developed by a 3rd party company, and that driver crashes your system because the devs at that company forgot to perform proper validation of data, well... that's on them. Even if MS wanted, they wouldn't be able to verify the soundness of any piece of code that is installed as a driver and runs with kernel level privileges. That'd require solving the halting problem.

↑