mettamagea day ago
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.
kungfufroga day 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!
sandosa day 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.
dmitrygra day ago
You can practice and you will get better very quickly. It really is a skill set that one can build.
koakuma-chana day ago
[flagged]
DaSHackaa day ago
Patches are welcome.
steveklabnika day 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.
tucnaka day ago
Unless your name is Kent, apparently.
freehorsea day ago
Sometimes.
zenmaca day 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!!!
jcalvinowensa day ago
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?
TacticalCodera day ago
[dead]
NooneAtAll3a day 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
kace91a day 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.
elrica day 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.
shmela day ago
English isn't his native language? Perhaps that's why
bluetomcata day 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.
charcircuita day 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.
pdwa day 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.
TheDonga day 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_VRa day ago
There’s the technical challenge, and then there’s the process challenge.
account42a day ago
Sending an email with a simple patch is not a challenge.
brooksta day ago
Thanks for submitting the fix here!
account4212 hours ago
You might want to read the thread you are responding to instead of posting knee-jerk reactions.
blueflowa day ago
"fixing bugs" gets lets street creds than "hacking into things"
TheDonga day 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_rsa day ago
>As opposed to fixing the bug?
God forbid someone does something for fun...
ch3a day ago
The author is Russian and seems to work for Positive Technologies, which is on the sanctions list.
darkwatera day ago
But he has an @linux.com email address though.
koakuma-chana day ago
What the hell is linux.com? .com is for commercial.
darkwatera day 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. "
Arch-TKa day ago
Interesting side effect of the sanctions.
shmela day ago
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?
Ygg2a day ago
I thought the idea is to prevent Russian hackers from introducing exploits. Not prevent Russian hackers from fixing exploits.
cyphar6 hours ago
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...
N_Lensa day ago
Would a more memory safe language like Rust in the Linux kernel have more safety against these types of exploits?
vlovich123a day 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.
steveklabnika day 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.
fsflover5 hours ago
How about security through compartmentalization instead of one through correctness that never really works? Consider using Qubes OS to protect yourself.
pasa day 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