From nobody Sat Jun 13 20:26:22 2026 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD4B73E929C for ; Tue, 5 May 2026 17:22:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778001747; cv=none; b=fjQYmbuOuMqvbK2tBanraBsAJvXYwrNOp0pXylbNKKTinRg1Sy6zjKyAuOqZ/e9qsgbBo9esP/hF5VgBhMeWoeaPsT1nmV+gtPcq6F4ikX20bP2LqW7yD4MSpso2cnuS8LI97Pc7D0qtS7wqEvCYC9GDCEfzCny3M41Mbhrb6IM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778001747; c=relaxed/simple; bh=+8CNpi9Emk9pvFDYp7sMDYqpu9yK+ln5XoO9066B0Ss=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hj1bm6kZbeu3aEsQsTz8/n87PKz3OAEFFOQ06gRDc8n29RERu7lg6Q9vQzvgTLJQgnU0yV+cw07DgMvlPI+1l0zJZbXgrtxoeJSI8fygHT5KNamhvBIpFPKuPW6DbEuTy6M3pSEjMHO0LjMd/uLSoIOIsK0lIid5f2OPQF3uzx8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hLwGriAS; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hLwGriAS" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4896c22fcbaso42431485e9.0 for ; Tue, 05 May 2026 10:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778001744; x=1778606544; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+mRnb7VtjjWLO9Am+98zCG8vyA2Azd5IwKeJ7qO7zuQ=; b=hLwGriASMVr9tae10bdZbvVF7jCZnxzaxH6rcQ/X9xUcJZvrZO9vHQF5rHICodkGO/ Dtpqo/8Jr6WauQ0B/OnybWuc2Gr+h66cfQDMK+tSOmHLv3GGcxWvuRCoe7+BJiRfYUQX c5By7jMFGBoQ3x6YBp5TknFmIVIGnSuMCGcZicAIJMqvgwFGdhwx8x+3LTB3WXdV/wg0 uEwNc1Z3V/LanzXk6qAn9pitcdbHHk7bLujgWUBAJMjzxAM/FG9c5eaRaLLLtw/+m6vI SPU/7jN7fxk8wjjCXSHes3HyQ4T4hTwnJk6Op6XD9AsoBMdDsGyYR+3hHnMXqb6930XH 0/Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778001744; x=1778606544; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+mRnb7VtjjWLO9Am+98zCG8vyA2Azd5IwKeJ7qO7zuQ=; b=OjM1BTyAZDy1Je9oRNykUkF59Am8jcztAVN2mXTgip/We08ErNEvyGYPggHUif/dw1 D3D7BJ9SWmsr4Hs9ZTi4zslaJRAT8s1yyFx1+OeIvMmOgeSTmulPFyLw9VNYZnlcVEbL q4ab4lhYHAWSane/E+gnjjqZTXCnBdUkB1V6QKpmyfPCi4543cnPQEZb7A5oRapFs1Tj BjoUA6PS2DuNRfSK2viadHQ7KQB4A2b55Zw4tpdrg6voxy/EBwUzoOxyUFK220JftXG2 3K97VQ11mGNN6RQjqk4rMCHH+Oj+/TfUyv50dfWgt/kJ6lHLkWkWNFPvjAhCkqUN+1Cp y7Tw== X-Forwarded-Encrypted: i=1; AFNElJ9fT6R8cc/Otwt0qoF9WlPtTmYeWIc0mqpuCW8y9k15xvc/9XiFAYaoMn7sBCl17UnGvEDH32XCMqtab94=@vger.kernel.org X-Gm-Message-State: AOJu0YwXSw2tga5lhpEgf8R2LfJ8Dk7LtpeMb1rpbKwnQt4eDnXkWo0X JHThMencBEnKMkRtj9wclHbZ9H21HaYJ3I9/bX/+NPKBd1glH5naa3C3 X-Gm-Gg: AeBDieviMCmOkqljFEenLQZUSZ1RwpUZ346MXAvtuIb34RsjGd2eY/1eNRcLIU1kb4Y oYEeHpfpD1v9FgWwpfz5uSfDNZ4C3TK2BoJ5g7i/X/dk99a2hD20I9cM9M0GqHXrC2vK5A1fAZp WKZCW+PFKR74vYbKXDn3XA8DUW4wS0wfH5x2Jkp/LNg5I8Skmpm1gYLJPBlAFU1LZ3HqdfXL0U4 1X1KtoCtNPks7HqFVTNeHr4reBQgVbuHvmKXXYTLPahM+VcV3FBkGZZx7DdEonK3X5OEY4luOzW 28WiaZKaiZlah+c+W02coEBTazNu+5TVvsGN7dK9tn/qsjaPEN/q/FXjpfSXqspl7D7BCm0PvzV s2jjWVODB1p0N/qY1VO06xNhnMo0lYTtcZUj2pOVdTUrHoayGSIhC5H87yjGBIM4mufp98UqwqF TngMPDJB6B4t4qYuzCQs0m45ss77lPklWAvK5T/GxeYn0m1HkJh4hSzGpO8znyg492TQK7bBWWL daFH0xFPui1uh4DMrG311IbcTFLmPNxxx928PBs7fFdCuGHzmfnHK4NpgW3bT0cibHWTbQ= X-Received: by 2002:a05:600c:3b17:b0:48a:568f:ae8a with SMTP id 5b1f17b1804b1-48e51e1a870mr2765905e9.8.1778001744152; Tue, 05 May 2026 10:22:24 -0700 (PDT) Received: from ahossu.localdomain ([82.78.232.184]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45055960902sm6640747f8f.28.2026.05.05.10.22.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 10:22:23 -0700 (PDT) From: Alexandru Hossu To: gregkh@linuxfoundation.org Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, error27@gmail.com, luka.gejak@linux.dev, stable@vger.kernel.org Subject: [PATCH v4 1/2] staging: rtl8723bs: fix OOB write and read in HT_caps_handler() Date: Tue, 5 May 2026 19:22:13 +0200 Message-ID: <20260505172214.3650398-2-hossu.alexandru@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260505172214.3650398-1-hossu.alexandru@gmail.com> References: <20260428091621.739680-1-hossu.alexandru@gmail.com> <20260505172214.3650398-1-hossu.alexandru@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" HT_caps_handler() iterates over pIE->length bytes and writes into HT_caps.u.HT_cap[], a fixed array of sizeof(struct HT_caps_element) bytes. pIE->length is a raw u8 from an over-the-air 802.11 Association Response frame and is never validated before the loop. A malicious AP can set it to 255, writing up to 229 bytes past the end of the array into adjacent fields of struct mlme_ext_info. Additionally, after the loop the function calls three macros that unconditionally read pIE->data[0] and pIE->data[1]: GET_HT_CAPABILITY_ELE_LDPC_CAP(pIE->data) -- reads data[0], bit 0 GET_HT_CAPABILITY_ELE_TX_STBC(pIE->data) -- reads data[0], bit 7 GET_HT_CAPABILITY_ELE_RX_STBC(pIE->data) -- reads data[1], bits 0-1 If a malicious AP sends an HT Capabilities IE with pIE->length less than 2, both bytes the macros need are outside the IE payload, causing an out-of-bounds read. Fix both issues: - Set HT_caps_enable =3D 1 first so HT negotiation is not regressed. - Return early if pIE->length < 2 to protect the macro reads. - Use umin() in the loop to bound the write side. The parallel HT_info_handler() already guards against oversized IEs. This patch applies the same discipline to HT_caps_handler(). Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Alexandru Hossu --- Changes in v4: - Add pIE->length < 2 guard after HT_caps_enable =3D 1 to prevent OOB reads from GET_HT_CAPABILITY_ELE_LDPC_CAP/TX_STBC/RX_STBC macros that access pIE->data[0] and pIE->data[1] unconditionally. Caught by sashiko review of v3. - Use umin() in the loop bound to cap writes at sizeof(HT_caps.u.HT_cap) without bypassing HT_caps_enable. Changes in v3: - Switch from min_t() to umin() (Dan Carpenter). - Keep truncation approach rather than early return so HT_caps_enable is always set before the length check (Luka Gejak, AI review). Changes in v2: - Replace early return before HT_caps_enable =3D 1 with umin() truncation so HT mode is not disabled for APs with oversized IEs. drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/stagi= ng/rtl8723bs/core/rtw_wlan_util.c index 6a7c09db4cd9..98aa50357e96 100644 --- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c +++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c @@ -936,7 +936,11 @@ void HT_caps_handler(struct adapter *padapter, struct = ndis_80211_var_ie *pIE) =20 pmlmeinfo->HT_caps_enable =3D 1; =20 - for (i =3D 0; i < (pIE->length); i++) { + if (pIE->length < 2) + return; + + for (i =3D 0; i < umin(pIE->length, + sizeof(pmlmeinfo->HT_caps.u.HT_cap)); i++) { if (i !=3D 2) { /* Commented by Albert 2010/07/12 */ /* Got the endian issue here. */ --=20 2.53.0 From nobody Sat Jun 13 20:26:22 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CBF64A2E10 for ; Tue, 5 May 2026 17:22:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778001749; cv=none; b=GPh4wiCJ9Ke/UVRKMJi9f9FMkAzittFFCI5iCxzaPoCygoMjd2QhPz3lRiywqjyfOKaEoEIe4j0vO2pZmHWdUysnWg2Edv+WtJZC/L24T8Ngx/rYf1+y3QE1KlmO3Rae/97r0liv93mF//79fF/PCxMXvuhOK2moKxZDWk4HcRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778001749; c=relaxed/simple; bh=JPZzn7zMNDqGfRZl0IeSI470609vvY5b/O/uV34wxbQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b12hDKH5kNsuWMhId4Jyk79XGyWiD4sZGaIqUmXVrQ26Q3rC2VaFm9HbTDK/xqQNOctn+73Z/iYmXoI04rTtllCTwUluSzW9wPqlszthNhnFiWOFeXPzzjq8qTwontBqQjZ9H57w5H95fDAEMG5sO+6eIiSLi/bIlPdh6avC7tQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Czbact+B; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Czbact+B" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-43d73352cf2so5043476f8f.1 for ; Tue, 05 May 2026 10:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778001746; x=1778606546; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=m/oPGZFJKTQjbJdiq9IFnoXRIzpps50+CWvpXCFG74k=; b=Czbact+Bq5DlfVlr+ZKaON8nSS9EEEn5xe+qso68Gt8Rq83Mg7ixc7kYc1yNVW7hgG lQ5eKLOnjdXMxJffw8yFTLguPe9Q5ncZvG1S2QYiHyU++ahEITBEsnarR0mi5VZ2IvlG xee4F2UGOGmojrPCa5MjJjYXANSHfoVxQeCtEp8YHucUK9x9oC95MOQhGP4zENa49DQE s97tFpse3SuzUlIPT5luR+eR7ExD+da1g+a79Szo1wcy6q6jZYZmZQKOWKqlx3RPk8SB B4K03evpzVmx0+atVKsc80sBwlku9/EbB2AZthc+qIHCZroc+z79PZa2uWMeuvUUuFNy Mshg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778001746; x=1778606546; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=m/oPGZFJKTQjbJdiq9IFnoXRIzpps50+CWvpXCFG74k=; b=pcB9bvcH1/j1zObLScg16uK+N7F+F0I21SV/wLScfeZBsNK2O2wz7sqmiTvGuFggnF xmww3xSQKD9VGxducHmaP+OljjD72J+fDodwVywNNiZWhO5ihvsDMSqE97R/51AjNW96 MDZ7oVrjQhIg2bZ3FdZn2+zEz1R+adP6iETjQFZ//h7riNYZW0aalxlrRoix/i4OBZQ2 Iebb1Oz3hkyG8qtB49IXdNKx5A7U7txdC8RBUKbpFtbIMRnT/J9hnKzUq+U9T6PHOg9e J0DKPFfMXg6Aa8+NDig7yAaHeY+R6EPLCXJ/dVSG81jHUdCqEgxwfh/DPrKlNVKrSAnj Y1Hw== X-Forwarded-Encrypted: i=1; AFNElJ+nKk/o834THvZG/C9DBB3uyHle9K+ZsrGJT3Db5KWj6Vbl3NC+IIU4ms09AnwG+aiH8KJbnwzi/m/+lu8=@vger.kernel.org X-Gm-Message-State: AOJu0Yy9ZfznOHGCFE84q5bWcLVQ/3ninmcmmV6zva3PqJ1VLvjotwm+ vBl/MmbQbIvwDOrR4jx9YVRD0x+dn0Up5+0kBQsdkvilsV5nIX6qSGMM X-Gm-Gg: AeBDieuHxy4DdIV2RdNyU/d5CilT9rF+sVU04Lh20m9ybpPnktlnvRQDzy0YVIoh8sl i/caf29mO6Fi0QPVT0m0RXRdLhEsATM0nTkfurzRuncpVprXLyH/QuAbyLDER2JNJLGu1Zg2Olm LcEn0c/5MXjtil54Jxx5JbsKoc5Cbs/MUJSOI23RoKOaaxuWZbZQ7xZvq+tBYw8q1WkVg9ic0yp k/6J1U4EYNQNTBjj9ILwnhdcS+L29quZFNezo1HbkcyKjkSyJsD4C8VhivhhlWAaNMN5i4JewVC ZlfizmtGPvSMzhn2joUqrS6x76pTHKWCE63fBrCM7X7dLddW0pr7oZEPPdhbV+zUuQRjE4Ik/bQ rIOnUleP7OskCJaB31IHwUQdV7nqSCluo6TECb8DuOM/pKitb107ShthZu1aH/OWDsfJHl4Xenw A2u+N0443FyN+9CdFQw0TVhj/GptQgEQ0s1QGc7jGJAGPaXuzh0VNFcKvMO10peML2HSlTdw3Yc zhHLZqR1bz0kqwqrmXHqBfBtbPjljB2emoSZUIeFj9bSpJ4vKlRQBD3fXmen6L3w8HApUbS9rTC anCaSQ== X-Received: by 2002:a05:6000:26c2:b0:449:c5e2:a8ad with SMTP id ffacd0b85a97d-4515b524480mr55229f8f.11.1778001745557; Tue, 05 May 2026 10:22:25 -0700 (PDT) Received: from ahossu.localdomain ([82.78.232.184]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45055960902sm6640747f8f.28.2026.05.05.10.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 10:22:25 -0700 (PDT) From: Alexandru Hossu To: gregkh@linuxfoundation.org Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, error27@gmail.com, luka.gejak@linux.dev, stable@vger.kernel.org Subject: [PATCH v4 2/2] staging: rtl8723bs: fix OOB reads in OnAssocRsp() IE parsing Date: Tue, 5 May 2026 19:22:14 +0200 Message-ID: <20260505172214.3650398-3-hossu.alexandru@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260505172214.3650398-1-hossu.alexandru@gmail.com> References: <20260428091621.739680-1-hossu.alexandru@gmail.com> <20260505172214.3650398-1-hossu.alexandru@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Three out-of-bounds read paths in OnAssocRsp(): 1. Missing minimum frame length check before fixed field reads. Before entering the IE loop the function reads capability, status, and AID from fixed offsets relative to pframe + WLAN_HDR_A3_LEN (at offsets +0, +2, and +4 respectively, so 6 bytes total). There is no check that pkt_len is large enough to cover these fields. A malicious AP can send a truncated Association Response frame shorter than WLAN_HDR_A3_LEN + 6 bytes, causing out-of-bounds reads and loading garbage into MLME state variables. 2. IE header and payload may extend past the packet end. The IE loop advances by pIE->length + 2 per iteration but only guards on i < pkt_len. When the last IE has only one byte left in the frame, the loop reads pIE->length from pframe[pkt_len], one byte past the receive buffer. Even when the header bytes are in bounds, pIE->length can point the data window past pkt_len, silently passing a truncated IE to the handler functions. 3. WMM OUI comparison reads 6 bytes past a possibly short IE payload. For WLAN_EID_VENDOR_SPECIFIC, the code calls memcmp(pIE->data, WMM_PARA_OUI, 6) without checking that pIE->length is at least 6. An attacker can craft a vendor-specific IE at the end of the frame with pIE->length smaller than 6. The existing IE bounds check only confirms the declared payload fits within pkt_len, not that it is large enough for the 6-byte OUI comparison. Fix all three: - Return _FAIL immediately if pkt_len < WLAN_HDR_A3_LEN + 6. - Add two guards in the IE loop: break if fewer than sizeof(*pIE) bytes remain, and break if the declared IE payload extends past pkt_len. - Guard the WMM OUI comparison with pIE->length >=3D 6. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Alexandru Hossu --- Changes in v4: - Add pkt_len < WLAN_HDR_A3_LEN + 6 check before reading the three fixed fields (capability, status, AID) to prevent OOB reads from truncated frames. Caught by sashiko review of v3. - Add pIE->length >=3D 6 guard before the 6-byte WMM OUI memcmp to prevent reading past a short IE payload. Caught by sashiko. Changes in v2: - Add IE header bounds check: break if i + sizeof(*pIE) > pkt_len. - Add IE payload bounds check: break if the declared IE data extends past pkt_len. drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/stagin= g/rtl8723bs/core/rtw_mlme_ext.c index 5f00fe282d1b..84cc814f069c 100644 --- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c +++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c @@ -1379,6 +1379,9 @@ unsigned int OnAssocRsp(struct adapter *padapter, uni= on recv_frame *precv_frame) =20 timer_delete_sync(&pmlmeext->link_timer); =20 + if (pkt_len < WLAN_HDR_A3_LEN + 6) + return _FAIL; + /* status */ status =3D le16_to_cpu(*(__le16 *)(pframe + WLAN_HDR_A3_LEN + 2)); if (status > 0) { @@ -1400,11 +1403,16 @@ unsigned int OnAssocRsp(struct adapter *padapter, u= nion recv_frame *precv_frame) /* to handle HT, WMM, rate adaptive, update MAC reg */ /* for not to handle the synchronous IO in the tasklet */ for (i =3D (6 + WLAN_HDR_A3_LEN); i < pkt_len;) { + if (i + sizeof(*pIE) > pkt_len) + break; pIE =3D (struct ndis_80211_var_ie *)(pframe + i); + if (i + sizeof(*pIE) + pIE->length > pkt_len) + break; =20 switch (pIE->element_id) { case WLAN_EID_VENDOR_SPECIFIC: - if (!memcmp(pIE->data, WMM_PARA_OUI, 6)) /* WMM */ + if (pIE->length >=3D 6 && + !memcmp(pIE->data, WMM_PARA_OUI, 6)) /* WMM */ WMM_param_handler(padapter, pIE); break; =20 --=20 2.53.0