grsecurity

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. Our recommendation: Apply the initial fix: https://git.kernel.org/pub/scm/linux/ kernel/git/torvalds/linux.git/commit/?id=3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 Ignore the fix for CVE-2026-53166 which introduced the worse DoS and was reverted just recently: https://git.kernel.org/pub/scm/linux/ kernel/git/torvalds/linux.git/commit/?id=39def6d250d370298f86c116f4ac60093cefadaa Apply this fix which addressed the same initial DoS issue without introducing another: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40a25d59e85b3c8709ac2424d44f65610467871e

@idkrn@infosec.exchange Usually prefer to mention things that are enabled by default and don't require configuration. In this RBAC case for instance, the policy is flexible and for backward compatibility reasons, subjects without connect/bind rules don't have socket family restrictions. A policy generated from full system learning shouldn't have this, but a later manual policy edit mistake could allow it.

@idkrn@infosec.exchange Sure, RBAC too, subjects with connect/bind rules automatically apply restrictions on socket families (limited to AF_UNIX/AF_INET). Any use of other socket families above that requires explicit sock_allow_family rules, so would block the AF_ALG use.

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://news.ycombinator.com/item?id=47956504

For it to be effective at all, you would need to have CONFIG_CRYPTO_USER_API_AEAD=m. If it's =y, there is no module and the mitigation is a no-op. https://oracle.github.io/kconfigs/?config=CRYPTO_USER_API_AEAD&amp shows the setting for common distros/versions, but it's most reliable to check your running kernel's config.

Creating a separate post so more people see this: the mitigation recommended by Theori.io for copy.fail *WILL NOT WORK* for any RHEL or RHEL-derived distro, including CentOS, Fedora, Oracle, and Alma as the vulnerable code is built-in.