[moring]

Let me rephrase my question: Is there actually such a thing as an "unexploitable use-after-free"? How would that look like? How would you reason that it is actually unexploitable?

Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.

[mort96]

Here's a stupid example:

    struct foo *whatever = new_foo();
    // use 'whatever'
    free_foo(whatever);
    if (whatever->did_something) {
        log_message("The whatever did something.");
    }
    // never use 'whatever' after this point

The 'whatever' variable is used after what it points to is freed, but it's not exploitable. Worst case, if new memory gets allocated in its place and an attacker controls the data in the offset of the 'did_something' field, the attacker can control whether we log a message or not, which isn't a security vulnerability.

[moring]

What happens if the code gets pre-empted between free_foo(whatever) and the if-statement, memory allocation gets changed, and subsequently dereferencing the pointer to read whatever->did_something causes a page fault?

I am making assumptions here: That pre-emption is possible (at least some interrupts are enabled), that "whatever" points to virtual memory (some architectures have non-mappable physical memory pointers), and that a page fault at this point is actually harmful.

However I do want to point out that the reasoning why your example is not exploitable isn't as easy as it first seems.

[mort96]

No preemption is needed, the call to free might unmap the page the pointer points to. I was considering adding a paragraph about that but didn't bother. A page fault isn't a privilege escalation issue though, it's a pretty normal thing.

[friendzis]

> How would that look like? How would you reason that it is actually unexploitable?

For use-after-free to be exploitable, by definition an attacker must be able to put arbitrary content at the memory region. This is not always easy: may require certain [mis]configuration, data layout and so on.

> practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.

I will not contest this claim, however there is a difference between "blow up" and "exploit". Malicious packet being able to segfault a server is one thing, malicious packet resulting in RCE is quite another. This may be a lost in translation moment when under colloquial use "exploit" does not include DoS.