@EdBoatConnoisseur >what exactly does crodwstrike falcon do?
I'm not exactly sure, but from what I've read it's a rootkit kernel module that goes and tries to scan signatures of exploits and tries to stop/report such exploits (as windows is Swiss cheese and countless remote-explotation vulnerabilities are constantly being exploited as I type this), with automated remote reporting and automatic updating of signatures.

To implement this "feature", it needs to have kernel-level access and as a result, the kernel module is pretty much a rootkit that adds the computer to their botnet.

Apparently after receiving their spying logs, they noticed that there was a massive infection campaign utilizing a vulnerability of named pipes on windows, so one of the verified-incompetent developers went and went and hastily whipped up a signature file to match the current infection wave and pushed it out in a panic to all computers without testing it.

The new signature files of course ended up being corrupted, but with a valid header - which the module at least verified, but due how the ingestion parser was poorly programmed, it choked on the invalid input and tried to de-reference a low pointer in memory that it's not allowed to access, which the NT kernel responds by triggering a BSOD.

Of course, every time windows rebooted, that module would be loaded and eventually it would get around to try to parse the corrupted files - although if the corrupted file is deleted, there's no longer a BSOD and if the computer is rebooted 15 or so times, eventually the driver manages to remotely download a correction patch to replace/delete x files before the crash occurs.

>also read it has caused outages on debian servers because they did not test the update on debian stable servers, which were supposedly a supported platform and configuration... But what does that shit do on the kernel space and why is it even used?
There is a GNU/Linux version as well, but that bug was completed different.

Rootkits really need to have proper root access to work, so previously it was implemented as a Linux module, except the clownstrike developers are so bad at programming and don't actually test anything, so many versions of the driver caused a kernel panic (very difficult to do, as de-referencing a null pointer for example just causes a kernel oops).

Many suckers after seeing a name appear in strings worked out that modules were being compiled on a developers personal machine and then pushed out without any testing.

The current version is now implemented as a eBPF program, as that VM/static analyzer is designed to make it difficult or impossible for anything running in the VM to crash Linux - but I'm sure they'll pull it off.

The main difference with the GNU/Linux version is that the sucker at least has control over when updates are installed and can test them on one machine before rolling them out to all of them.