Since Friday, when a faulty CrowdStrike content update crashed millions of Windows machines, Linux administrators have been pointing out something the headlines missed: this had already happened to them, twice, this year. It just didn't ground any airlines.
I covered Friday itself in understanding the causes of widespread outages. Here's the earlier part of the story.
April: Debian
In April, an engineer at a civic technology lab described every one of their Debian servers crashing at the same time and refusing to boot. After working through it, they traced the cause to a CrowdStrike Falcon sensor update that was incompatible with the current Debian stable release, which CrowdStrike listed as a supported configuration. According to the engineer's later account, CrowdStrike acknowledged the problem and reproduced it, but the fix took weeks, and the root cause, a configuration nobody had tested, sounded very familiar after Friday.
May and June: RHEL 9.4 and Rocky Linux
When Red Hat Enterprise Linux 9.4 shipped in May, a new problem appeared. Machines running the Falcon sensor could kernel panic after booting the 9.4 kernel. Red Hat published a knowledge-base article attributing the panic to the falcon-sensor process, and as a temporary measure advised disabling the sensor. Users of Rocky Linux 9.4, a RHEL rebuild, reported freezes after upgrading. Some found that switching the sensor between its eBPF-based user mode and its kernel-module mode avoided the crash, while others rolled back to the previous kernel.
Why it keeps happening
These aren't three unrelated bad days. They're the same structural problem showing up on different operating systems:
- Endpoint security agents run with maximum privilege. On Windows that means a kernel driver. On Linux it means a kernel module or eBPF programs hooked deep into the kernel. When they misbehave, they don't crash an application. They crash the machine.
- The agent and the operating system move independently. A distribution updates its kernel on its own schedule. The vendor updates its agent and its detection content on another. Every combination is a configuration someone has to test, and the number of combinations across Linux distributions and kernels is large.
- Updates reach everyone at once. Content updates in particular are pushed fleet-wide, quickly, by design, because security vendors are racing attackers.
eBPF helps on Linux, because the verifier stops a broken program from loading. But eBPF's guarantees cover the program, not every interaction with the kernel underneath it, so it reduces the risk without removing it.
What would actually help
- Staged rollouts for everything, including "just content." Canary groups, then gradual widening, with automatic stop if crash rates rise.
- Customer control over timing, so critical systems can sit a few hours or a day behind.
- Testing against current distribution releases, before they ship rather than after customers report crashes. RHEL betas and Debian testing are public.
- Transparency. Publishing exactly which kernels and distributions each agent version is tested on, and post-incident reports when something breaks, as a matter of course.
- Open source the sensor for community review. Customers and distributions could then see exactly what a privileged agent is doing and test it against their own kernels before it reaches production, and a far wider pool of reviewers would have a chance to catch the next problem first. It's not a substitute for staged rollouts, since an open agent pushed everywhere at once would fail the same way, but the two together would be far stronger than either alone.
For administrators
- Pin and stage agent updates where the product allows it, and push your vendor where it doesn't.
- Hold kernel updates on a small canary group for a few days when you run third-party kernel agents.
- Know your recovery path for a machine that won't boot: console access, a rescue image, and on Windows, your BitLocker recovery keys.
- Keep the old kernel installed. On Linux, booting the previous kernel is often the fastest way out.
A correction
October 2026. An earlier version of this article listed a series of other CrowdStrike incidents from 2019 to 2024, including Linux kernel panics, Windows blue screens, macOS extension failures and network interruptions. I can't find reliable sources for those, so I've removed them. The Debian and RHEL incidents above are documented by the people who experienced them and, in RHEL's case, by Red Hat. I should have checked the rest before publishing it.
Since then
Added October 2026. CrowdStrike's own review of the Windows outage, and its promise of staged deployments and customer control over content updates, are covered in the CrowdStrike post-mortem and the postmortem of the July 2024 outage.