More stable kernels with partial Dirty Frag fixes [LWN.net]

Greg Kroah-Hartman has released the 6.1.171, 5.15.205, and 5.10.255 stable kernels, quickly followed by 6.1.172 and 5.15.206 kernels. This is another round of stable kernels to provide fixes for one of the CVEs (CVE-2026-43284) assigned following the Dirty Frag and Copy Fail 2 security disclosures. There is not, yet, a stable kernel with a fix for CVE-2026-43500, though a patch to fix the second half is in the works.

to post comments

Pardon the naive question...

Posted May 9, 2026 17:59 UTC (Sat) by NightMonkey (subscriber, #23051) [Link] (7 responses)

... but is there a path to determining if these security vulnerabilities have been exploited *in the past*? Since these are 'zero-days', I'd like to be able to investigate a system I'm responsible for and determine with some certainty that a past breach has occurred.

I know it is of course difficult (and perhaps impossible, really) because you cannot rely on a system that has been compromised to report on it's own condition, but I thought I'd see if the community has some insights or approaches. But, perhaps there's a way to scan the storage of such a suspect system after booting from an known-uncomporomised kernel? Is there a project that takes that approach?

Cheers.

Pardon the naive question...

Posted May 9, 2026 20:50 UTC (Sat) by ballombe (subscriber, #9523) [Link]

Normally one use aide or tripwire to detect this.

Pardon the naive question...

Posted May 9, 2026 21:13 UTC (Sat) by tuig (guest, #183721) [Link]

It's called an Intrusion Detection System, or IDS for short. The 4 A's (authentication authorization, accounting and auditing) help secure your box and an IDS can be your canary in the coal mine. None of this can guarantee anything because there's always room for error and the halting problem. No amount of software, free or non-free can work around the physics of the machine.

Pardon the naive question...

Posted May 10, 2026 21:12 UTC (Sun) by tarvin (guest, #4412) [Link]

You can use the package manager to identify files which no longer have the checksum which they had at package install time.

For the Debian family:
dpkg --verify

For the RedHat/SUSE family:
rpm -Va

Here you need to trust that the kernel, glibc and the package panagement binaries haven't been modified to lie about file contents.
Some of the output will be irrelevant, because certain files are meant to be changed after installation.
Not all software is installed via packages, it will not catch everything.

Pardon the naive question...

Posted May 11, 2026 0:51 UTC (Mon) by cypherpunks2 (guest, #152408) [Link] (3 responses)

Despite what some others are saying, no it is not possible to determine if a system was compromised in the past, even if you boot from an uncompromised kernel. The exploit is only resident in memory and disappears as soon as the mapped pages that were modified get faulted back in, which can happen due to the very memory pressure caused by verifying all binaries or just by the exploit itself. After all, nothing stops it from dropping the page cache on its own after doing the dirty deed.

Also, it's only the proof-of-concept that modifies setuid binaries in the page cache, but the vulnerability lets you modify anything in the page cache, including content that will never be checked by dpkg (like modified configuration files) or content that is dynamic and won't be checked by an IDS. If you have an arbitrary write primitive to all of the page cache, it's trivial to evade detection.

Maybe running dpkg --verify would protect against a script kiddie who is using the unmodified PoC, but that's not going to be much better than something obviously pointless like history | grep curl.

Pardon the naive question...

Posted May 11, 2026 10:33 UTC (Mon) by epa (subscriber, #39769) [Link] (1 responses)

Like finding bugs, you can sometimes find out that your system was compromised, but you can never prove that it was not.

Pardon the naive question...

Posted May 15, 2026 17:42 UTC (Fri) by cypherpunks2 (guest, #152408) [Link]

In that case I wouldn't say that using an IDS would detect this exploit or it'll create a false sense of security. It would be better just to say that you might be able to catch a sloppy script kiddie using an IDS but that you shouldn't rely on it as a detection mechanism. Just imagine someone in 2018 asking "how do I find out if someone used the DirtyCoW exploit on my system?" and someone else replied "normally one uses history | less to detect this".

Pardon the naive question...

Posted May 11, 2026 16:57 UTC (Mon) by tuig (guest, #183721) [Link]

Verifying checksums with the package is useful after filesystems somehow got damaged. It's not useful as a way to detect ownage. Querying the box itself for ownage is pointless. "Nothing to see here, pinky promise!"

Flatten and rebuild is better and even that might not be enough when the box itself can reprogram an eeprom. This is why hardware freedom has become at least as important as software freedom. Easier to audit, inspect and generally reason with.