It was not cherry-picked to 21.02:
https://github.com/openwrt/openwrt/pull/10363
Bests
Nick
On 7/31/22 19:35, Hauke Mehrtens wrote:
On 7/24/22 15:28, Sakura Industries wrote:
In the ubus support patch for bss transition management responses,
the target_bssid variable is left uninitialized if the client refuses
to transition for any reason. This leads to random segfaults in
hostapd when it marshals the ubus message, because it de-references
this uninitialized pointer to build the message.
There is no target_bssid for any response other than accept, so the
patch just sets the variable to NULL. The ubus code properly handles
that case. This issue is only noticable if one is using a band
steering agent like dawn.
Signed-off-by: Steven Johnson <[email protected]>
---
diff --git
a/package/network/services/hostapd/patches/600-ubus_support.patch
b/package/network/services/hostapd/patches/600-ubus_support.patch
index 4abb6887f6..737fa2ff61 100644
--- a/package/network/services/hostapd/patches/600-ubus_support.patch
+++ b/package/network/services/hostapd/patches/600-ubus_support.patch
@@ -552,8 +552,9 @@
sta->agreed_to_steer = 1;
eloop_cancel_timeout(ap_sta_reset_steer_flag_timer, hapd, sta);
eloop_register_timeout(2, 0,
ap_sta_reset_steer_flag_timer,
-@@ -530,6 +532,10 @@ static void ieee802_11_rx_bss_trans_mgmt
+@@ -530,6 +532,11 @@ static void ieee802_11_rx_bss_trans_mgmt
MAC2STR(addr), status_code,
bss_termination_delay);
++ target_bssid = NULL;
}
+ hostapd_ubus_notify_bss_transition_response(hapd, sta->addr,
dialog_token,
The problem was already fixed some months ago here:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9b880f09f394049e0629e3c9d4061f431a6b19a8
Hauke
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
