Ask the list, not the field: our use-after-free in the Linux kernel

This one is ours. A fuzzing run against the code that holds IPsec security associations turned up a use-after-free, we wrote the patch, and it now ships in every maintained stable branch of Linux. We are writing it up because the shape of the mistake is more useful than the crash.

The question the code was asking

When the kernel deletes an IPsec state, it has to take that object off four hash lists. For two of them, the code decided whether to unhash by looking at a value: does the state have a sequence number, does it have an SPI. That is a proxy for the question that actually matters, which is whether the object is on the list.

Most of the time the proxy and the truth agree. Under concurrency they can drift apart, and when they do, the delete path either skips an unhash it needed or performs one it should not have. A second delete of the same object then writes through a pointer that was poisoned the first time. The same function already asked the right question for the two lists added more recently. The older ones were never brought into line.

before:
if (x->km.seq)
        hlist_del_rcu(&x->byseq);
if (x->id.spi)
        hlist_del_rcu(&x->byspi);

after:
if (!hlist_unhashed(&x->byseq))
        hlist_del_init_rcu(&x->byseq);
if (!hlist_unhashed(&x->byspi))
        hlist_del_init_rcu(&x->byspi);

Two changes, and they do different jobs. Asking the list instead of the field makes the decision track reality. Re-initialising the node on delete makes a second delete a harmless no-op rather than a write through poison.

A field is a claim about state

This is the same failure we keep writing about in agent systems, one layer down. A field that says the object has an SPI is a claim about where the object is. The list is the fact. Code that trusts the claim works until something changes one without the other, and concurrency is exactly that something.

An agent that trusts a tool's description instead of what the tool does, a permission check that trusts a label instead of the resource, a delete path that trusts a scalar instead of the list: different layers, one habit. Trust is the attack surface, including the trust a function places in its own bookkeeping.

What the patch deliberately does not do

It does not chase down the single interleaving that frees the object twice. It makes the delete idempotent and the guard truthful, so the consequence goes away whichever path gets there first. The maintainers accepted it on those terms. A fix for the one race we happened to catch would have been narrower and would have left the next one in place.

The part that never makes it into a CVE

The first version did not apply. It went out through a web mail client, which stripped every tab from the diff, and it had no Fixes: tag. The maintainer asked for the tag, the stable maintainer replied with the form letter pointing at the stable rules, and the resend through git send-email was applied the next morning.

That tag is not paperwork. It is the mechanism that carries a fix into older trees, and without it this patch would have landed in mainline and stopped there. Every downstream fix in the ledger exists because one line named the commits that introduced the bug.

Where a kernel bug ends up

A crash found in cloud virtual machines now appears in an industrial controller advisory and in long-term enterprise kernels that most people assume are frozen. That is the practical point for anyone buying hardware: your exposure is not your own kernel version. It is every appliance running Linux that you did not build, patched on its vendor's schedule rather than upstream's.

What to actually do

• Move to the first fixed release of your stable branch. The ledger lists them. Long-term branches got the fix weeks after mainline, so check rather than assume.
• If you cannot patch yet, look at unprivileged user namespaces. The low-privilege rating rests on them. Hosts that do not need them lose that path.
• Ask your appliance vendors where they stand. Controllers, firewalls and storage boxes run kernels you never see. One industrial vendor has listed this as affected with no fixed firmware yet.
• If you review kernel or systems code, look for proxy guards. Any condition that tests a value as a stand-in for membership, ownership or state is worth replacing with a test of the thing itself.