HN Reader

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!

>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?

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

Would a more memory safe language like Rust in the Linux kernel have more safety against these types of exploits?

>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.