Dear Maintainer,

When wpa_supplicant runs an access point (mode=2 / AP mode, as NetworkManager's
"hotspot" or shared-mode Wi-Fi does), it crashes with SIGSEGV as soon as the AP
interface receives a DPP Presence Announcement ("chirp") from any nearby Wi-Fi
Easy Connect device. No interaction or association is needed: a nearby device
that chirps is enough. One wpa_supplicant usually serves every Wi-Fi interface,
so the crash also drops any client-mode connections, and it repeats on every
chirp (19 crashes in about 90 minutes in one field log).

Cause: in AP mode, wpa_supplicant hands received management frames to hostapd's
code (ap_mgmt_rx -> ieee802_11_mgmt -> hostapd_dpp_rx_action).
hostapd_dpp_rx_action
reads hapd->iface->interfaces->dpp, but wpa_supplicant's AP code never sets
iface->interfaces, so the read goes through NULL. Standalone hostapd sets it and
is not affected. The client-mode DPP path is not affected either.

Upstream fixed this in hostap commit 9cb7b0bce (2025-01-09, "DPP: Discard DPP
Action frame in AP mode if no global DPP context"), which adds a 4-line guard at
the top of hostapd_dpp_rx_action. It is in hostap 2.12. The commit names
e00f780e2 ("DPP2: hostapd as TCP Relay", 2019) as the cause, so 2.9 through 2.11
are affected. None of trixie 2:2.10-24, forky/sid 2:2.10-25 or experimental
2:2.11-2 carries it.

Upstream commit:
https://git.w1.fi/cgit/hostap/commit/?id=9cb7b0bce

Reproduction (two Debian trixie arm64 devices, Raspberry Pi OS):
 1. Device A: stock 2:2.10-24, NetworkManager AP on channel 6.
 2. Device B, on a Wi-Fi interface in client mode:
      wpa_cli -i <iface> dpp_bootstrap_gen type=qrcode
      wpa_cli -i <iface> dpp_chirp own=1 iter=1
 3. Device A logs "wlan0: DPP-RX src=<B> freq=2437 type=13" and wpa_supplicant
    segfaults in the same second; NetworkManager shows every Wi-Fi interface as
    supplicant-failed until it restarts.

With 9cb7b0bce applied to the 2:2.10-24 source as an extra debian/patches entry
(it applies with an offset), the same test sends 5+ chirps over 3.5 minutes with
no crash; the wpa_supplicant PID stays the same, and client-mode DPP on the
other interface still works. We have run that patched build on several devices
since 2026-09-14 with no side effects.

Since any nearby chirping device can repeatedly take down a Linux access point
built on wpa_supplicant, a backport to trixie (e.g. through a stable update)
would be appreciated.

Thank you.