[SECURITY] hostap - PASN responder: missing Authentication frame

[Jouni Malinen]

On Tue, Aug 18, 2026 at 12:15:11PM +0400, Elman Shahbazov wrote:
> length validation causes integer underflow and undefined behavior in
> handle_auth_pasn_1() / handle_auth_pasn_3()

> I would like to responsibly disclose an input-validation / memory-safety
> issue discovered in the PASN responder code of hostap (current master,
> commit <COMMIT>). The issue was found via coverage-guided fuzzing
> (AFL++ 5.02c, afl-clang-fast with ASAN+UBSAN) using the project's own
> fuzzing harness tests/fuzzing/pasn-resp.

> The PASN responder entry points handle_auth_pasn_1() and
> handle_auth_pasn_3() in src/pasn/pasn_responder.c parse the Information
> Elements of a received Authentication frame using a length computed as:
> 
>     len - offsetof(struct ieee80211_mgmt, u.auth.variable)      /* = 30 */
> 
> WITHOUT first validating that len >= offsetof(struct ieee80211_mgmt,
> u.auth.variable).

As noted later, that check is done by all the callers of production
code, i.e., this is not a security vulnerability. The only case that can
hit this issue is the pasn_resp test tool for fuzzing.

> 3. ROOT CAUSE
> 
> CWE-20  Missing Input Validation
> CWE-191 Integer Underflow (unsigned wrap-around of "len - 30")
> CWE-475 Undefined Behavior at API boundary (pointer overflow)
> 
> The safety contract ("len must cover the fixed Authentication fields")
> is not enforced by the callee; every caller happens to re-implement the
> check independently (see section 5), which is exactly the pattern that
> leads to remotely exploitable bugs the moment one caller forgets it.

Well, it would be quite unlikely for that to happen in code other than
special testing tools since those fixed fields are needed to process the
Authentication frames. The root cause here is really in that fuzzing
tool not enforcing that.

> 5. CALLER AUDIT / REACHABILITY

> Current in-tree callers and their validation:
> 
> - src/ap/ieee802_11.c (handle_auth, check at line 4241:
>   "len < IEEE80211_HDRLEN + sizeof(mgmt->u.auth)")      -> validated
> - src/p2p/p2p.c (p2p_handle_pasn_auth:
>   "len < offsetof(...u.auth.variable)")                  -> validated
> - src/common/proximity_ranging.c (pr_pasn_auth_rx:
>   "len < offsetof(...u.auth.variable)")                  -> validated
> - src/nan/nan_pairing.c (nan_pairing_process_elems:
>   "len < offsetof(...u.auth.variable)")                  -> validated
> 
> So in the current tree the missing validation is masked. However:

Which is why this is not a security issue..

> 6. IMPACT ASSESSMENT
> 
> In a production (non-sanitized) build the wrapped length makes the
> element-iteration terminate immediately

In production builds, the length is checked in the callers, so this case
is not reachable..

> 7. SUGGESTED FIX
> 
> Enforce the contract inside the callee (defense in depth):
> 
> --- a/src/pasn/pasn_responder.c
> +++ b/src/pasn/pasn_responder.c
> @@ -846,6 +846,9 @@ int handle_auth_pasn_1(struct pasn_data *pasn,
>          u32 i;
> 
> +       if (len < offsetof(struct ieee80211_mgmt, u.auth.variable))
> +               return -1;
> +
>          if (!groups)
>                  groups = default_groups;
> 
> @@ -1255,6 +1258,9 @@ int handle_auth_pasn_3(struct pasn_data *pasn,
>          u8 hash[SHA512_MAC_LEN];
> 
> +       if (len < offsetof(struct ieee80211_mgmt, u.auth.variable))
> +               return -1;
> +
>          if (ieee802_11_parse_elems(mgmt->u.auth.variable,
> 
> Optionally, for consistency, change the "len < 24" check in
> handle_auth_pasn() (src/ap/ieee802_11.c, ~line 4097) to
> "len < offsetof(struct ieee80211_mgmt, u.auth.variable)".

It seems reasonable to add these explicit checks in PASN code itself (at
least to fix the fuzzing tool, if for no other observable benefit in
practice), so I applied this:
https://git.w1.fi/cgit/hostap/commit/?id=d6100aa8d0c1b01d998693593efa4778a5950b6f

-- 
Jouni Malinen                                            PGP id EFC895FA