KERNSEAL™ is now officially KERNSEAL®

It's now available to beta testers!

We expect our 7.1 beta to be available for testing within the next two weeks.

Apply the initial fix: git.kernel.org/pub/scm/linux… Ignore the fix for CVE-2026-53166 which introduced the worse DoS and was reverted just recently: git.kernel.org/pub/scm/linux… Apply this fix which addressed the same initial DoS issue without introducing another: git.kernel.org/pub/scm/linux…

the fix referenced by that CVE introduces a worse DoS (busy loops on all CPUs in the kernel), and has no CVE yet to inform users. We discovered this second DoS early last month through routine inspection. Our recommendation:

If you're just now hearing about GhostLock and looking to fix it, make sure you don't introduce two unpriv-reachable DoSes associated with its fixes. The fix the Linux CNA lists for CVE-2026-43499 introduces a NULL deref, which caused CVE-2026-53166 to be issued. Unfortunately...

KERNSEAL makes the linear page cache overflow in cyberstan.co.uk/fuse-readdir… deterministically unexploitable. Serial log below 👇

It's now available!

We expect our 7.0 beta to be available for testing within the next two weeks.

Correcting the above: in terms of LTS kernels it's 5.10+, but the 2020 commit came in Linux 5.6 (so would affect for instance some Ubuntu 20.04 kernels as well on 5.8)

Yes, it now has CVE-2026-46333 : lore.kernel.org/linux-cve-an…

We don't recommend the '3' setting (which rejects all attach-like ptrace_may_access() requests, regardless of privilege level) as once set, it is locked to that value until reboot.

As mentioned at openwall.com/lists/oss-secur… , distro users can echo 2 > /proc/sys/kernel/yama/ptrace_scope to mitigate. Keep in mind this will break some normal usage, like preventing unprivileged use of strace, gdb, etc entirely.

There hasn't been one published and no sign in the Linux CNA's vulns.git of one having been allocated yet still, as of now.

We've just published a Knowledge Base article with more information about the vulnerability, current published/unpublished exploits, and current mitigations. We still recommend patching ASAP.

Multiple suid binary targets, please do not rely on individual ones you see posted as effective mitigations. Current exploits are only gaining read access to [/]etc[/]shadow, but can't guarantee read/write to something useful isn't possible.

Exploits are now appearing targeting pidfd, which is forced into all Linux kernels since 5.10 (2020), no module or initcall to blacklist this time, must patch ASAP!

We've just sent a detailed mail to all customers notifying them of this issue, with split-out fixes available for 5.15, 6.6, and 6.18. We'll share more information on our Knowledge Base as it becomes available.

The commit message makes no mention of it, but we believe the goal of exploiting the vulnerability would be to target a suid root binary that drops its privileges while retaining privileged access to a file on exit that via the vuln an unprivileged user could gain access to.

We've uploaded new patches for 5.15, 6.6, and 6.18 to address an obfuscated upstream Linux logic vulnerability that should exist in all kernel versions: git.kernel.org/pub/scm/linux…