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.
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!
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.
You can practice and you will get better very quickly. It really is a skill set that one can build.
[flagged]
Patches are welcome.
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.
Unless your name is Kent, apparently.
Sometimes.
>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!!!
I was very disappointed the SLAB_VIRTUAL patches stopped, there weren't really major objections to them.
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?
[dead]
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
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.
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.
English isn't his native language? Perhaps that's why
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.
Would a more memory safe language like Rust in the Linux kernel have more safety against these types of exploits?
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.
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.
... 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
How about security through compartmentalization instead of one through correctness that never really works? Consider using Qubes OS to protect yourself.
>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.
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.
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.
There’s the technical challenge, and then there’s the process challenge.
Sending an email with a simple patch is not a challenge.
Thanks for submitting the fix here!
You might want to read the thread you are responding to instead of posting knee-jerk reactions.
"fixing bugs" gets lets street creds than "hacking into things"
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?
>As opposed to fixing the bug?
God forbid someone does something for fun...
The author is Russian and seems to work for Positive Technologies, which is on the sanctions list.
But he has an @linux.com email address though.
What the hell is linux.com? .com is for commercial.
"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. "
Interesting side effect of the sanctions.
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?
I thought the idea is to prevent Russian hackers from introducing exploits. Not prevent Russian hackers from fixing exploits.
No, the point is to stop Amercian technology companies from providing technology to Russian entities.
From the perspective of sanction laws, accepting patches (or arguably even replying to emails) from sanctioned entities is effectively providing technology to them because you are telling them that the patch solves the issue (i.e., you are providing them technical expertise) and are making it easier for them to use the patch in the future (i.e., no need to rebase and shipping software that they have indicated that they will find particularly useful).
The Linux Foundation provided some guidance about this earlier this year[1]. Basically, it is incredibly easy to inadvertently violate sanctions if you are involved in an open source project.
[1]: https://www.linuxfoundation.org/blog/navigating-global-regul...