The truth about the CrowdStrike crash - it was a null pointer

[FranceBB]

I'm sure everyone knows that OS can run things in user space and kernel space. The overwhelming majority of programs run in user space (which is abstracted away), so that if something bad happens, the program crashes but the user can go on with his life as it doesn't affect the rest of the OS. Only few things are supposed to run in kernel space and of course drivers are one of those things since they need direct access to the hardware. Unfortunately, when things go wrong in kernel space, the OS cannot do anything to recover, which is exactly what happened when Crowdstrike released the infamous update on Thursday evening that brought the world to a halt. As to "why" an antivirus runs to run in kernel space with a driver, let's just say that antiviruses integrate with the OS at a low level. Lots of machines installed the update and ended up bluescreening, bringing things from local businesses unable to access cash registers to fuel pumps not allowing people to refuel their cars as they wouldn't process payments, to broadcasters unable to insert graphics and overlays or even broadcast at all, to airlines having to ground flights... It was horrible. On Friday morning, lots of people just went on to delete the new C-00000291 driver from C:\Windows\System32\drivers\CrowdStrike in safe mode to then reboot the various machines across the globe. I was one of them as I did that on plenty of servers and workstations across the company I work for (a very big broadcasting company). We had everything down, including the domain controllers. Then, once those were back up and running, at around 09.35AM CEST CrowdStrike released an update with the new driver. Now, the interesting thing is not that Windows bluescreened, but why it bluescreened, which leads to the question: what was the deal with the old driver? We may not have the source code from CrowdStrike, but what we have is the sequence of instructions that the CPU executes collected in the crash dump.



The interesting line from the crash dump (in the picture) is

mov r9d, dword ptr [r8]

For those who are familiar with x86 assembly, it's read in reverse, so take the data referred by the pointer r8 and move it into r9. In other words, the instruction mov r9d, dword ptr [r8] in x86 assembly means that the 32-bit value (since dword stands for "double word," which is 32 bits) located at the memory address pointed to by r8 is moved into the lower 32 bits of the r9 register. In simpler terms, it dereferences the pointer r8 to get the value stored at that memory location and then stores that value in r9d (the lower 32 bits of r9). All good, right? Well, not quite. The problem is that r8 is completely empty, therefore Windows enters an irrecoverable state and bluescreens as it cannot access the data.