Linux Security Hardening Cache Randomization Was Inadvertently Using The Same Seed
Ahead of the upcoming Linux 6.15 kernel cycle a few early pull requests have already been sent in to Linus Torvalds in advance of the anticipated v6.14 release on Sunday. Among those early changes for Linux 6.15 are the SLAB allocator updates that include a fix for cache randomization with kvmalloc inadvertently being inadequate due to accidentally using the same randomization seed.
With the SLAB pull request ahead of the Linux 6.15 merge window, most notable besides a few minor improvements is improving the kmalloc cache randomization within the kvmalloc code.
Google engineers discovered that the CONFIG_RANDOM_KMALLOC_CACHES hardening feature wasn't properly being employed. CONFIG_RANDOM_KMALLOC_CACHES creates multiple copies of slab caches and makes kmalloc randomly pick one based on the code address in order to help fend off memory vulnerability exploits. But the problem was the same random seed always ended up being used with the current Linux kernel code. From the Google code comments:
Gong Ruiqi of Huawei who worked out the solution to the issue explained:
At least with these pending SLAB updates for the Linux 6.15 merge window, this issue will be resolved and presumably be likely back-ported to existing stable kernels to address this ineffective security hardening.
With the SLAB pull request ahead of the Linux 6.15 merge window, most notable besides a few minor improvements is improving the kmalloc cache randomization within the kvmalloc code.
Google engineers discovered that the CONFIG_RANDOM_KMALLOC_CACHES hardening feature wasn't properly being employed. CONFIG_RANDOM_KMALLOC_CACHES creates multiple copies of slab caches and makes kmalloc randomly pick one based on the code address in order to help fend off memory vulnerability exploits. But the problem was the same random seed always ended up being used with the current Linux kernel code. From the Google code comments:
"...This is problematic because `__kmalloc_node` will use the return address as the seed to derive the *random* cache to use. Since all calls to `kvmalloc_node` will use the same seed when the size is large, the hardening is rendered completely pointless."
Gong Ruiqi of Huawei who worked out the solution to the issue explained:
"That literally means all kmalloc invoked via kvmalloc would use the same seed for cache randomization (CONFIG_RANDOM_KMALLOC_CACHES), which makes this hardening non-functional.
The root cause of this problem, IMHO, is that using RET_IP only cannot identify the actual allocation site in case of kmalloc being called inside non-inlined wrappers or helper functions. And I believe there could be similar cases in other functions. Nevertheless, I haven't thought of any good solution for this. So for now let's solve this specific case first.
For __kvmalloc_node_noprof, replace __kmalloc_node_noprof and call __do_kmalloc_node directly instead, so that RET_IP can take the return address of kvmalloc and differentiate each kvmalloc invocation."
At least with these pending SLAB updates for the Linux 6.15 merge window, this issue will be resolved and presumably be likely back-ported to existing stable kernels to address this ineffective security hardening.