Foundational security for the Linux kernel. Solving the most difficult memory unsafety problems. Created by @opensrcsec
Joined June 2012
- Tweets 3,612
- Following 1
- Followers 8,898
- Likes 58
278 Photos and videos
Jun 3
We expect our 7.0 beta to be available for testing within the next two weeks.
2
9
1,275
May 14
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!
May 14
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.
2
33
114
24,798
May 16
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)
1
2
1,166
May 15
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.
1
1
765
May 15
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.
542
May 15
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.
May 14
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!
2
4
13
3,850
May 14
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.
May 14
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…
1
17
19,469
May 14
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…
1
11
46
8,561
May 14
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.
2
7
2,438
May 8
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.
3
5
2,084
May 7
Fixes for Dirty Frag (seclists.org/oss-sec/2026/q2…) 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.
3
17
68
8,512
May 7
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.
1
1
5
1,535
Apr 30
The KB article with links to the combined/split-out patches for 5.15 and 6.6 (adapted to grsecurity) are now available.
Apr 30
Patches are now available, KB article next with links to the combined/split-out patches
4
1,913
Apr 30
Patches are now available, KB article next with links to the combined/split-out patches
Apr 30
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)
2
6
3,825
Apr 30
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)
3
11
3,296
Apr 29
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.
2
5
54
10,427
Apr 30
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): news.ycombinator.com/item?id…
10
63
11,532