grsecurity

grsecurity

@grsecurity.bsky.social

Foundational security for the Linux kernel. Solving the most difficult memory unsafety problems. Created by @opensrcsec

247 followers2 following36 posts

All affected users must patch against php2shell (CVE-2026-109618 / CVE-2026-109619). Due to the nature of some of the primitives involved, ASLR is not effective and arbitrary code execution/reuse/filesystem-level execution isn't a necessary component of exploitation in this case.

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, 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.

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.

grsecurity@grsecurity.bsky.social

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!

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!

grsecurity@grsecurity.bsky.social

We've just sent a 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.

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.

We've just sent a 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.

grsecurity@grsecurity.bsky.social

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/linu...

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 published a detailed KB article for customers on the two vulnerabilities involved in Dirty Frag and the associated public exploits, feel free to reach out with any questions.

The KB article with links to the combined/split-out patches for 5.15 and 6.6 (adapted to grsecurity) are now available.

grsecurity@grsecurity.bsky.social

Updated 5.15 and 6.6 patches are now available. We're now preparing a KB article with more guidance than shared in last night's email with links to combined/split-out patches for both 5.15 and 6.6 for those on older kernels who need CONFIG_CRYPTO_USER_API_AEAD enabled (which shouldn't be anyone)

Updated 5.15 and 6.6 patches are now available. We're now preparing a KB article with more guidance than shared in last night's email with links to combined/split-out patches for both 5.15 and 6.6 for those on older kernels who need CONFIG_CRYPTO_USER_API_AEAD enabled (which shouldn't be anyone)

Today, Mathias Krause of our team has submitted patches for the NVIDIA open gpu kernel modules that implement full Kbuild support, paving the way for CFI, KASAN/UBSAN, and our many compiler plugins. Running AI workloads with NVIDIA GPUs no longer means weakening kernel security. Links below 👇️

Just sent out our year end wrap-up mail to customers. It's a bit bigger than usual, so grab yourself some Swiss Miss and enjoy! If you didn't receive it, but should have, just reach out and we'll make sure you're on the list. Happy holidays!

Quick reminder that our 6.8 short-term stable kernel goes EOL at the end of this month. Some stats: over the period of a year, it included over 1500 security/stability-relevant backports.

Nice demo: tested a vulnerable Ubuntu 22.04 system for glibc CVE-2025-4802 using Solar Designer's PoC adapted to Ubuntu (replace any occurrence of "myhostname" with "mdns4_minimal"). Even an old #grsecurity 5.4.96 kernel from February 8 2021 prevented exploitation

We need to post a correction to yesterday's eBPF performance numbers: Mathias Krause wasn't happy with just a 30x speedup and took a look at one final bottleneck that was bothering him. The speedup over vanilla is now 747x 🤯 (5.27s vs 1h5m40s)

grsecurity@grsecurity.bsky.social

Performance isn't the enemy of security: we care about both. Today's patches finish off a set of security/performance improvements to eBPF. Below we show a ~30x speedup vs vanilla in running the eBPF selftests with every single #grsecurity option enabled!

Performance isn't the enemy of security: we care about both. Today's patches finish off a set of security/performance improvements to eBPF. Below we show a ~30x speedup vs vanilla in running the eBPF selftests with every single #grsecurity option enabled!

If you're curious, we also fixed the failing vanilla testcases, without which the speedup would have appeared even larger than 30x. Every grsecurity option really means every single one, including RAP, PRIVATE_KSTACKS, KERNEXEC, UDEREF, AUTOSLAB, KERNSEAL, etc.

You are up to date.