1. Their code was calling a 21-parameter "matcher" function with 20 parameters of data.
2. They didn't notice, because all the matcher rules had "allow anything" for the 21st parameter and so never looked at it.
3. They later published the first list of rules with something other than "allow anything" as the 21st parameter, direct to customers.
4. On customer machines, the first rule with a non "match everything" 21st parameter went to look at the 21st element of the 20 element array. It expected a string pointer, but instead there was random stack data. It tried dereferencing this to read the string it was expecting, which caused the kernel driver to segfault during early startup, putting customer machines in a boot loop.
1. Their code was calling a 21-parameter "matcher" function with 20 parameters of data.
2. They didn't notice, because all the matcher rules had "allow anything" for the 21st parameter and so never looked at it.
3. They later published the first list of rules with something other than "allow anything" as the 21st parameter, direct to customers.
4. On customer machines, the first rule with a non "match everything" 21st parameter went to look at the 21st element of the 20 element array. It expected a string pointer, but instead there was random stack data. It tried dereferencing this to read the string it was expecting, which caused the kernel driver to segfault during early startup, putting customer machines in a boot loop.
https://www.crowdstrike.com/wp-content/uploads/2024/08/Chann...