this post was submitted on 20 Jul 2024
479 points (97.8% liked)
Linux
4945 readers
135 users here now
A community for everything relating to the linux operating system
Also check out [email protected]
Original icon base courtesy of [email protected] and The GIMP
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
There's a concept in this industry where you eat your own dog food.
Deploying these updates to your own people could have avoided this mess.
Oh but they did. Turns out that this is specifically caused by one driver expecting another to be installed, the other one being for another of their products. If you have the other product installed, it doesn't crash, so it didn't crash on their machines because they have all their products installed and apparently not a single element of their test matrix has the single most common configuration they service
Do you have a source for that? I'm intrigued. Their own blog post is only talking about a "logic error".
I heard a different rumor, that the driver file they pushed was all zeros. I'm inclined to believe that one.
They were talking about the Linux instance, not the windows one.
It's a very educated guess based on the following:
The crash is a null pointer dereference, which a linter ought to catch.
The crash does not happen if you have crowdstrike sensor installed, which is weird because crowdstrike sensor's job is not to prevent any crashes.
Hence the guess: the update the pushed tries accessing memory in sensor, but if it's not installed the pointer is null and that's Bye-Bye.
I see, thanks for the clarification. Sounds plausible.
This is the best explanation of this I've heard and you're just like... A dude on Lemmy.