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.
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...
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...
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.
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?
mettamage•5mo ago
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.