Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

> If anything having a macro kernel makes it quite hard to shut down a module like this to determine if it was well behaved with respect to memory

Unloading modules is generally possible, but I'm not quite following what shutting it down has to do with checking memory use?

View on HN

Use-after-free bugs are pretty easy to figure out on shutdown because you can free the remainder of your working memory and if it turns out that you have a use-after-free there likely will be a double free in there somewhere.

If not then the problem is more insidious but I've found plenty of use-after-free bugs that way.

Most exploited UAFs don't happen in common execution paths. They're often caused by weird races and error conditions that nobody considered to even happen. It's why things like production ASan is a lot less valuable than people would imagine: most reasonably well tested software doesn't exhibit memory corruption when used normally. So, sure, your suggested technique could be a cool way to try and catch bugs that appear under normal execution but it won't put that much of a dent in the total number of bugs.

That may well be true, even so debugging a kernel module is quite a lot harder than a regular process so the fact that it is a kernel module by itself probably increases the chances of such bugs being present. Especially because you are not in control of the execution context.

Reply on news.ycombinator.com