--- schema: 1 kind: vulnerability title: "Linux kernel bridge STP timer use-after-free — a control-flow hijack primitive with a published exploit, no CVE, and no confirmed stable backport" headline: "Arming a bridge's STP timers without an interface-up guard yields a freed-object reclaim, reachable only with bridge-management privilege" summary: > SSD Secure Disclosure published a use-after-free in the Linux kernel's software bridge STP implementation, submitted by two researchers during TyphoonPWN 2026. A bridge that is administratively down while kernel STP is enabled, with a port driven into the LEARNING state, arms periodic timers without an interface-up guard; the timer object is embedded in structures freed with the bridge, so reclaiming the slot with attacker-controlled data yields a control-flow hijack primitive. The precondition is bridge-management privilege — not network-reachable and not available to a plain unprivileged process — a precondition this entry assesses rather than quotes, since neither source states it. No CVE was assigned, a compilable exploit is published inline, the mainline fix landed 2026-06-30, and backport status beyond mainline is unconfirmed. discovered_at: "2026-08-10T04:58:00Z" event_date: "2026-08-05" run_id: 2026-08-10T0411Z-intel priority: notable immediate_action: null tags: [vulnerabilities, lpe, priv-esc, poc-public, patch-available] regions: [global, europe] sectors: [public-sector, technology] entities: [] techniques: [T1068] affected_products: ["Linux kernel"] cves: [] sources: - url: "https://ssd-disclosure.com/linux-bridge-stp-timer-use-after-free/" publisher: "SSD Secure Disclosure" date: "2026-08-05" role: primary - url: "https://github.com/torvalds/linux/commit/2a00517db8de" publisher: "Linux kernel" date: "2026-06-30" role: primary closed_sources: [] evidence: - quote: "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." publisher: "SSD Secure Disclosure" - quote: "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" publisher: "Linux kernel" - quote: "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." publisher: "SSD Secure Disclosure" - quote: "Two independent security researchers, n132 and sven sze, submitted this during our TyphoonPWN 2026 and won second place in the Linux PE category." publisher: "SSD Secure Disclosure" verification: multi-source sourcing_note: > The advisory is the technical primary; the upstream fix commit is independent vendor-side confirmation of the same root cause, fetched through a source-code mirror after the kernel's own git host refused every transport with an anti-bot challenge. No CVE identifier exists — confirmed by its absence from both the advisory and the commit message, and none is invented here. The commit message carries no stable-tree tag, so whether distribution kernels have taken the fix could not be established and is reported as unknown rather than assumed either way. The privilege precondition is stated in the body as this entry's own assessment because neither source addresses it; the mainline fix date is taken from the commit itself, which predates the advisory by roughly six weeks. confidence: high update_of: null references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: B credibility: 1 watchlist_hit: false actions: [] migrated_from: null --- 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](https://ssd-disclosure.com/linux-bridge-stp-timer-use-after-free/)). 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](https://github.com/torvalds/linux/commit/2a00517db8de)). 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. **Defender takeaway:** confirm whether the running kernel includes the mainline fix of 2026-06-30, which is a more answerable question than it looks given the six-week lead on the advisory. Beyond that, the control that matters is which principals on a host can perform bridge-management operations at all — tightening that removes the reachable path regardless of patch state, and it is worth doing first on hosts running untrusted or multi-tenant workloads.