Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Hi On Tue, Apr 23, 2024 at 09:20:08AM +0200, Bastian Blank wrote: > On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote: > > On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org > > wrote: > > > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike > > > Falcon Sensor on all our machines, virtuals servers and laptops alike. > > > That would explain why I don't have the same problem at home. > > Okay, so closing this bug report. Please don't come back with machines > > in this state. > While you are at it, please extract the kernel module from Crowdstrike > and ask them for the obviously GPL marked module. Can I please get a response? Bastian -- Sometimes a feeling is all we humans have to go on. -- Kirk, "A Taste of Armageddon", stardate 3193.9
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote: > On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org wrote: > > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike > > Falcon Sensor on all our machines, virtuals servers and laptops alike. > > That would explain why I don't have the same problem at home. > Okay, so closing this bug report. Please don't come back with machines > in this state. While you are at it, please extract the kernel module from Crowdstrike and ask them for the obviously GPL marked module. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Control: reassign -1 src:linux Control: severity -1 normal Control: tags -1 moreinfo On Mon, Apr 22, 2024 at 09:12:59AM +0200, bouv...@buxtehude.debian.org wrote: > Something seems wrong in 6.1.0-20, but it is not immediately wrong: it waits > until some sort of trigger. After that, rebooting over and over is of no use. > I > cannot make any sense of it. Can you? I see: "Tainted: E", this means you are running unsigned kernel modules. However I don't see any sign of it in the list of kernel modules. Also the "O" taint, meaning out-of-tree build, did _not_ trigger. So, whatever this module is, it is pretty broken on it's own. Please identify the process messing with the kernel, remove it and come back. You can find it by searching for "unsigned" in the kernel log. To disallow such modules, enable secure boot or add "lockdown=integrity" to the kernel command line. Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, "Wolf in the Fold", stardate 3615.4
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike Falcon Sensor on all our machines, virtuals servers and laptops alike. That would explain why I don't have the same problem at home. -- Cédric Bouvier System Engineer, IRU Geneva +41-22-918 2927 (direct) https://www.iru.org
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Seeing this same issue. In my case, it ended up being caused by Crowdstrike Falcon Sensor combined with this specific kernel. Reverting the kernel or upgrading Falcon (via Falcon upgrade policy) works around this issue, for now. I think I see that 6.1.87 has attempted to fix some BHI implementation issues that were originally introduced in 6.1.85. Perhaps certain kernel modules aren't ready for this syscall hardening?
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Same problem here, but with a different call trace. The RIP logline had one of `security_file_permission` and `security_netlink_send`, I don't remember which one.
