Linux kernel bridge STP timer use-after-free — a control-flow hijack primitive with a published exploit, no CVE, and no confirmed stable backport

SSD Secure Disclosure has published a use-after-free in the Linux kernel's software bridge implementation, submitted by two researchers to its TyphoonPWN 2026 competition, where it took second place in the Linux privilege-escalation category (SSD Secure Disclosure, 2026-08-05).

The bug is a missing state check rather than a memory-handling slip. The bridge driver arms periodic spanning-tree timers that live embedded inside the bridge's own private data, and the arming path reached when a port transitions into the LEARNING state does not verify the bridge is administratively up: "A bridge that is administratively down while kernel STP is enabled, together with a port driven into the LEARNING state, arms periodic STP timers without an IFF_UP guard." The upstream fix commit identifies the specific omission — "This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free" (Linux kernel, 2026-06-30). Because the timer is embedded in a structure freed along with the bridge device, an attacker who deletes the bridge while a timer is still armed leaves a live reference to freed memory, and the exploitation step follows directly: "So as long as we refill the freed slot with a buffer carrying an attacker-controlled function pointer, we obtain a control-flow hijacking primitive." A full compilable exploit is published inline with the advisory, and the upstream fix, which landed in mainline on 2026-06-30 — roughly six weeks before the advisory published — restores the missing guard.

The precondition decides how much this matters, and neither cited source states it directly, so it is set out here as this entry's own assessment rather than as reported fact. What the sources do establish is the shape of the exploit: it creates a bridge, enables kernel spanning-tree on it, drives a port into the learning state and deletes the bridge. Those are privileged bridge-management operations, not actions available to an ordinary unprivileged process, and the flaw is therefore not network-reachable. Where the assessment goes beyond the sources is in the routes by which that privilege is commonly held — an attacker already at root seeking kernel-context execution, a workload deliberately granted network-administration rights, or a host permitting unprivileged namespace creation. Operators should confirm which of those applies on their own systems rather than take the generalisation from here. What the advisory itself supports is only that its authors "won second place in the Linux PE category".

Two gaps in the record are worth carrying rather than glossing. No CVE was assigned by anyone, so a purely identifier-driven patch or scanning process will not surface this. And the fix commit carries no stable-tree marking, so whether any given distribution kernel has taken it could not be established this run — though the six-week gap between the mainline fix and the public advisory means the window for a backport to have propagated is wider than the advisory date alone suggests. That is a question for each operator's own build, not something to assume in either direction.

Detection, telemetry class first. The exploitation sequence is unusual enough to hunt for directly in system-call or netlink audit telemetry: bridge creation, enabling kernel STP, driving a port into the learning state, and deleting the bridge, performed in quick succession by a principal that is not the host's configuration management. On hosts with kernel debugging facilities enabled, a freed-object-still-active warning naming the bridge topology-change timer is the crash-side artefact. Triage: container runtimes and network plugins create and tear down bridges constantly, so bridge lifecycle events are ordinary infrastructure noise — the discriminators are the actor and the STP state, since the orchestrators that legitimately manage bridges generally do not enable kernel STP on them, and a namespace-confined or non-root principal performing the sequence has no routine reason to.