Damn, I don't have the time. I've been reading for 20 minutes and I really need to get back to work, haha.
I love how this blog post describes a use after free, all its limitations and then next steps to deal with all of it. In many cases this would be like a 2 to 4 part blog post but this just all is written in one go. I could keep my attention span for about half of it. This would be fun to recreate in a course or something. Also, I didn't know you could slow down the execution time of certain code.
kungfufrog 17 hours ago [-]
This makes me realise how useless I really am when things get low-level enough. Super impressed with the talent and ability of serious exploit researchers!
sandos 14 hours ago [-]
I love reading the Google project zero blogs. Very humbling, even though I started programming very low-level (x86 assembly) I am so far from that world today.
dmitrygr 11 hours ago [-]
You can practice and you will get better very quickly. It really is a skill set that one can build.
koakuma-chan 17 hours ago [-]
[flagged]
DaSHacka 17 hours ago [-]
Patches are welcome.
steveklabnik 13 hours ago [-]
Not only that, but your parent is just plain incorrect: those patches are being accepted. It’s true that some drama existed, but that’s not the majority of what’s been going on.
tucnak 16 hours ago [-]
Unless your name is Kent, apparently.
freehorse 16 hours ago [-]
Sometimes.
zenmac 14 hours ago [-]
>no I hire those who finish the tasks, even when the competition is over...
this is epic!!!
Just reading the pics are worth the upvote the post. Wish can double vote this one. It exhibits one of human ingenuity beyond the realm of competition that the current world so focused on. Provo!!!
jcalvinowens 14 hours ago [-]
I was very disappointed the SLAB_VIRTUAL patches stopped, there weren't really major objections to them.
...but I don't think that type based approach would have made any difference with this exploit?
TacticalCoder 15 hours ago [-]
[dead]
NooneAtAll3 17 hours ago [-]
fascinating topic, but does anyone else feel like the text is hard to read?
something about choice of words and sentence structure feels... un-prose-like
kace91 17 hours ago [-]
I’m a not a native speaker so take it with a grain of salt, but I think it’s the cadence of phrases.
Writers can use it as a tool by playing with the length and complexity of phrases - to create speed or calm, for example.
When the rythm doesn’t change, and there’s a succession of similar-length simple statements for a long time, it sounds robotic after a while:
“I run this command. Then that problem happened. This caused something else . I addressed the issue. Something else happened. Now I adress it.”
This is not a criticism toward the author to be clear, I was just curious about what caused your feeling and checked.
elric 15 hours ago [-]
I thought it made for a clear and pleasant read. Not sure what your hangup is, but to each their own. "Un-prose-like" sounds like a compliment.
shmel 17 hours ago [-]
English isn't his native language? Perhaps that's why
bluetomcat 16 hours ago [-]
Their English is sufficiently good. It's a cultural aspect regarding writing style. When Russians and most Eastern Europeans write about technical subjects, they tend to be concise, dense and straightforward. Americans, on the other hand, are over-expressive and tend to saturate their writing with pointless metaphors and rhetorical devices.
charcircuit 18 hours ago [-]
>Convinced the path forward would be painful, I shelved the bug.
As opposed to fixing the bug? Either the incentives are broken for security researchers to fix bugs, contributing fixes to Linux is broken, or both.
A rewrite of these user interactable subsystems in Rust can't come soon enough.
pdw 18 hours ago [-]
Security researchers rarely fix bugs. They don't see it as their job, and it requires a very different skill set than finding or exploiting them anyway.
TheDong 18 hours ago [-]
This is misplaced in this case.
The author mentioned CVE-2021-26708, which is very similar to this bug, and in fact the author both exploited it and authored the upstream fix in the kernel.
> and it requires a very different skill set than finding or exploiting them anyway
I disagree with that. Exploiting bugs is really hard, and if you can exploit them, you absolutely know enough about the kernel in order to patch it.
Sure, architecting a kernel, making code maintainable, that's a software engineering skill. But fixing a use-after-free? That's easier than exploiting it, of course they can fix it.
Den_VR 17 hours ago [-]
There’s the technical challenge, and then there’s the process challenge.
account42 16 hours ago [-]
Sending an email with a simple patch is not a challenge.
brookst 16 hours ago [-]
Thanks for submitting the fix here!
blueflow 15 hours ago [-]
"fixing bugs" gets lets street creds than "hacking into things"
TheDong 18 hours ago [-]
I mean, yes, the incentives are in fact such that sitting on a potentially exploitable bug is better for a security researcher than patching it early.
Like, if you have a root priv escalation, that can potentially get you a bug bounty from various hosted AI sandboxes, CI sandboxes, an android app sandbox escape, and probably a few more.
If you have a probably-not-exploitable kernel crash, you get a CVE at best, and possibly not even that.
What do you propose we do, should google assume all kernel bugs are potential exploits and give Linus $100k per commit, making him the richest man on earth?
rs_rs_rs_rs_rs 17 hours ago [-]
>As opposed to fixing the bug?
God forbid someone does something for fun...
ch3 18 hours ago [-]
The author is Russian and seems to work for Positive Technologies, which is on the sanctions list.
darkwater 16 hours ago [-]
But he has an @linux.com email address though.
koakuma-chan 16 hours ago [-]
What the hell is linux.com? .com is for commercial.
darkwater 14 hours ago [-]
"Linux.com is brought to you by The Linux Foundation, the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Please see www.linuxfoundation.org for more information on The Linux Foundation, its mission and its members. "
Is it really a side effect though? I think the entire point of these sanctions (or their implementation by Linux Foundation more specifically) is to prevent developers working for Russian companies from contributing to Linux. It isn't a side effect, it's the intended effect, wouldn't you say so?
Ygg2 14 hours ago [-]
I thought the idea is to prevent Russian hackers from introducing exploits. Not prevent Russian hackers from fixing exploits.
N_Lens 13 hours ago [-]
Would a more memory safe language like Rust in the Linux kernel have more safety against these types of exploits?
vlovich123 13 hours ago [-]
Hard to say. It is a write after free which rust technically prevents, but it depends on the abstractions chosen; it’s entirely likely there will be similar attacks that focus on exploiting flaws in the unsafe that will exist to trigger similar flaws. It should just be harder to exploit and easier to enforce that most of the kernel code is using “safe” abstractions.
steveklabnik 13 hours ago [-]
I just glanced at the patch, but “more safety” is at least directionally correct; given that the kernel could use unsafe code, it’s in theory still possible, but I would expect this code wouldn’t be written in unsafe directly.
pas 7 hours ago [-]
... a better type system, hygienic macros, and of course more static analysis (like Rust's borrow checker), and everything helps that makes writing safer abstractions easier, makes them easier to test and verify
Rendered at 03:28:12 GMT+0000 (Coordinated Universal Time) with Vercel.
I love how this blog post describes a use after free, all its limitations and then next steps to deal with all of it. In many cases this would be like a 2 to 4 part blog post but this just all is written in one go. I could keep my attention span for about half of it. This would be fun to recreate in a course or something. Also, I didn't know you could slow down the execution time of certain code.
this is epic!!!
Just reading the pics are worth the upvote the post. Wish can double vote this one. It exhibits one of human ingenuity beyond the realm of competition that the current world so focused on. Provo!!!
Recently there's a patch which tries to use clang's new alloc token thing to partition kmalloc: https://lore.kernel.org/lkml/20250825154505.1558444-1-elver@...
...but I don't think that type based approach would have made any difference with this exploit?
something about choice of words and sentence structure feels... un-prose-like
Writers can use it as a tool by playing with the length and complexity of phrases - to create speed or calm, for example.
When the rythm doesn’t change, and there’s a succession of similar-length simple statements for a long time, it sounds robotic after a while:
“I run this command. Then that problem happened. This caused something else . I addressed the issue. Something else happened. Now I adress it.”
This is not a criticism toward the author to be clear, I was just curious about what caused your feeling and checked.
As opposed to fixing the bug? Either the incentives are broken for security researchers to fix bugs, contributing fixes to Linux is broken, or both.
A rewrite of these user interactable subsystems in Rust can't come soon enough.
The author mentioned CVE-2021-26708, which is very similar to this bug, and in fact the author both exploited it and authored the upstream fix in the kernel.
> and it requires a very different skill set than finding or exploiting them anyway
I disagree with that. Exploiting bugs is really hard, and if you can exploit them, you absolutely know enough about the kernel in order to patch it.
Sure, architecting a kernel, making code maintainable, that's a software engineering skill. But fixing a use-after-free? That's easier than exploiting it, of course they can fix it.
Like, if you have a root priv escalation, that can potentially get you a bug bounty from various hosted AI sandboxes, CI sandboxes, an android app sandbox escape, and probably a few more.
If you have a probably-not-exploitable kernel crash, you get a CVE at best, and possibly not even that.
What do you propose we do, should google assume all kernel bugs are potential exploits and give Linus $100k per commit, making him the richest man on earth?
God forbid someone does something for fun...
https://www.linux.com/about/