grsecurity

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

[grsecurity @grsecurity]

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

[grsecurity @grsecurity]

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)

[grsecurity @grsecurity]

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]

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.

[grsecurity @grsecurity]

@thingwhere Yes, it now has CVE-2026-46333 : https://t.co/UrLoIilpeN

[grsecurity @grsecurity]

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]

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]

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.

[grsecurity @grsecurity]

As mentioned at https://t.co/Te5MKCkBu8 , 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.

[grsecurity @grsecurity]

@thingwhere 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.

[grsecurity @grsecurity]

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.

[grsecurity @grsecurity]

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: https://t.co/qdnNlRzRTf

[grsecurity @grsecurity]

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.

[grsecurity @grsecurity]

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: https://t.co/qdnNlRzRTf

[grsecurity @grsecurity]

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.

[grsecurity @grsecurity]

The upstream rxrpc vulnerability affects >= 6.5. The second vuln reusing the same "Dirty Frag" naming requires unprivileged userns to exploit as an unprivileged user, disabled in grsecurity since it first existed.

[grsecurity @grsecurity]

Fixes for Dirty Frag (https://t.co/K9PbJrmenw) were already included in our current 6.6 and 6.18 patches from May 4th. No distro builds in CONFIG_AF_RXRPC, so MODHARDEN should be generally effective against unprivileged exploitation.

[grsecurity @grsecurity]

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]

Patches are now available, KB article next with links to the combined/split-out patches

[grsecurity @grsecurity]

Patches are now available, KB article next with links to the combined/split-out patches

[grsecurity @grsecurity]

We'll have updated 5.15 and 6.6 patches available shortly (despite 5.15 being EOL) along with split-out patches available 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)

[grsecurity @grsecurity]

We'll have updated 5.15 and 6.6 patches available shortly (despite 5.15 being EOL) along with split-out patches available 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)

[grsecurity @grsecurity]

For RHEL/RHEL-derived configurations, this approach will work (the function name has been stable since 2015 and initcall_blacklist has been supported since 2014): https://t.co/DJh67yMqh0

[grsecurity @grsecurity]

Creating a separate post so more people see this: the mitigation recommended by https://t.co/e2Cwqzet1X for https://t.co/1DsFYvMk41 *WILL NOT WORK* for any RHEL or RHEL-derived distro, including CentOS, Fedora, Oracle, and Alma as the vulnerable code is built-in.

[grsecurity @grsecurity]

Don't rely on mitigation suggestions from others floating around: non-readable suid binaries only does something for this specific exploit, it's exploitable in other ways that don't involve suid binaries at all.