https://www.phoronix.com/news/Linux-6.15-slab
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:
"...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.
- https://www.phoronix.com/news/Linux-6.15-Likely-Features
- https://lore.kernel.org/lkml/2f7985a8-0460-42de-9af0-4f966b937695@suse.cz/
- https://github.com/google/security-research/blob/908d59b573960dc0b90adda6f16f7017aca08609/pocs/linux/kernelctf/CVE-2024-27397_mitigation/docs/exploit.md?plain=1#L259
- https://patchwork.kernel.org/project/linux-mm/patch/20250212081505.2025320-3-gongruiqi1@huawei.com/
(Score: 4, Funny) by c0lo on Sunday March 23, @03:21AM (1 child)
Lemme guess, it was 4 [xkcd.com]?
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by Freeman on Monday March 24, @02:37PM
Perhaps my favorite xkcd of all time. Yes, we have a random number generating function. Why do you ask? Well, it seems to always return the same number . . .
It's the kind of thing you think can't possibly happen. Yet, it's the kind of thing that is easy enough to forget.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 4, Funny) by RamiK on Sunday March 23, @09:20AM
The Chinese are undoing American backdoors... The Americans are undoing Chinese backdoors... Win-win I say.
compiling...
(Score: 1, Funny) by anubi on Sunday March 23, @11:59AM (4 children)
Get the time.
MD5 or SHA it. Use that for a random seed?
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by turgid on Sunday March 23, @12:11PM (3 children)
What's wrong with thermal noise or radioactive decay?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Interesting) by anubi on Sunday March 23, @12:51PM (2 children)
Just no new hardware needed. I am taking it that the environment already has functions to retrieve a time string, or posix time, but that is sequential and not nearly random enough. So use a cryptographic hash to mix things up beyond recognition.
I used to do a similar thing back in the 80's when using the assembler to code games...being I was already polling for keyboard activity, I did a few rotates, increments, and xor's of the last key press adding to whatever was left from before on each loop of the poll, to give me the next "random" number, usually 8 bits. Just needed something different every time. 6502 machine. Well, it was quick and good enough that the game didn't repeat as no way could I repeat the same amount of polling loops between keystrokes, and the xor's and rotated just about guaranteed the numbers wouldn't be close to the last number generated.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by turgid on Sunday March 23, @01:47PM (1 child)
I believe x86 CPUs have had thermal noise random number registers for quite a while now.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Insightful) by anubi on Sunday March 23, @10:10PM
The 386 was the last machine I wrote machine code for...that was back in the days we took great pride in crafting precision code.
These days, we don't think that much about writing a "hello, world!" that has megabytes of dependencies as well as correspondingly large attack surface.
I never knew there even was a way to access die temp on the simple stuff I worked on...heck we didn't even heat sink them.
https://stackoverflow.com/questions/5327203/how-to-access-cpus-heat-sensors [stackoverflow.com]
I figured on a modern machine, I probably couldn't even access keyboard registers anymore without all sorts of gyrations, but a call to system time and a call to encrypt something was probably already supported by the system.
By the time the nineties, and the corresponding dominance of "business computing" took hold, and "artisanal computing" went the way of the skilled mechanic, we now have environments full of canned off-the-shelf canned solutions instead of custom work.
It's the economy of scale thing. One size fits all. Can be inefficient as hell, but it's cheap. If it breaks, buy another. It's not even worth the time to see how it worked. Artisans may spend years designing things, while it often takes only minutes to make a purchase decision. Everything is a trade-off. Heck, I am even entering this comment via a phone, using technology I thought was impossible when I was a kid, who thought an AM radio transmitter was really high tech.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by turgid on Sunday March 23, @12:14PM
Take off your tinfoil hat and get the random numbers [random.org] THEY want you to have. The Martians told me. It must be true. Now excuse me while I send an encrypted transmission to Zeta Reticuli.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].