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.

[grsecurity@infosec.exchange]

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.

[grsecurity@infosec.exchange]

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&
shows the setting for common distros/versions, but it's most reliable to check your running kernel's config.

[grsecurity@infosec.exchange]

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

[idkrn@infosec.exchange]

@grsecurity you said grsec can be vulnerable “only MODHARDEN has a chance.” What about rbac?

[grsecurity@infosec.exchange]

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