From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 34BA928F50F for ; Mon, 23 Feb 2026 15:24:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771860244; cv=none; b=FHBaL3JBdHbigSvlQXCz7Fc78w0l2XSUsONLbgJ1qBvraQ7V5lzD2KV9J8nfAiOCXIvwohBb7Dp3x84AbGb/CHV213syPAmCkkQo0kmzKgc+o0tKbs7vvogmZQTi6FpSJ+ukuQqHqsRVUkZ8zOftIFWJX5fbPuBjmp1NGHrGDCM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771860244; c=relaxed/simple; bh=uZQ/q45shpIHP8um1RNoNVIfOi+Xa4L7kQEnXL00K1k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EO+QvKYFXe5ZP093JV6emonHorHhVXvDeBQ0qSF/E2Z8i8Bi6YVI0e3p1AiUM0COYZJrRiY3pvbawJZEzofo/b9JUdrvDRKtZCHiFDAoRbK+2atxn1e4tXa20QxYqsVMHkGhl6m0FZDc2B6M1c1dVRCSJQGONHRfKBJjobpGOes= 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=cijkaHn4; arc=none smtp.client-ip=209.85.214.173 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="cijkaHn4" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2a77c1d5c3bso18299985ad.0 for ; Mon, 23 Feb 2026 07:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771860240; x=1772465040; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5ly3i63vTZlJq8RbN/SeN0Gc5gVMXziAUej0ugffmJ8=; b=cijkaHn49/4mBRjq5HifGPiIb8lX6D79oa31zp3WJt2BuxfRdWuhybzneu5A1vw4K8 s/tN4t4p9wnTmQyJnGVaxvS3ZbnRoYQPsXi5lktVfQW3TJrcaxG0YvjVdAD32aZK4NzY jGYk0teBL4lFTwsNByobbjjwXRL52vOTQNhdfwMFnJtaD6hlJ3Nf8fCoyluusoHKCfXc AYab/6m6r9j0abk4VVCYB4g9XIKgbBIF+MHl/ilESD9s/gZIiwJ5NI5gYUaQzP69u1b/ 7jPUxlR1kTSVA6KdACcjyCoXVJSMYvL0GNyvJG8qB9z5Ozcc+hzd6vLr3Z34X9Z0BfpV 8FWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771860240; x=1772465040; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5ly3i63vTZlJq8RbN/SeN0Gc5gVMXziAUej0ugffmJ8=; b=Ny8llGyvshKWUuqtXSnxjDpm9nE0RdsbWN9DXFoeQ99G9+GiF1EK0Jjr534cZKOMlI 9YW5v0sKKZRGMDw1U+Dyu4HcIO9aVW3EQS3CFtb5h2/WHQuv5pCzWKBvjF0kROoWd33g H1btXKGa6bcefU3mMD9/mwPssMpmrFwp/erYdmikK906NhiBcAl1nw3uxIt8ZeY4gtM7 oSNcOyHRL4b9NJE9oKgWCQ9Cc4Yx3zdiUAYV4GPT3QIQvIs2FCS80HqJXNZ2PtiZEwVN EAVNgWBU+kIt2uFCWPu6EuzjihRHIZBPeCI+YRsv1SgDggpbl4pAbYqihnkZA4zQJ5v6 xNxQ== X-Gm-Message-State: AOJu0YxGDHfu9YjC5AAd1mU+/4X6kVYdZd8+HAsYzbIyWF9cVIh0ixU5 Nm2oQ9jgJgYFMIdXlkio1QXkPpO7VrPSf0eisyXj1UjR+t9T5kvnmFap X-Gm-Gg: ATEYQzznyYH8RUz2ByXDtmxYR8hCjo3+5xg17aZ8ESMvyFsLDNmrayutGnlYWGfI3qe fG7bpe52QJh1KiFmZNau2yq5ToGbU7C7EpdCgV58sa28z0yT5BDF5/ng/1+7iAmK6ukGYZINEfV QdC/3dmlzQG9vX8JguACNx/cQD0knMRSa3EU0IcM2yR524U8wX/UTmlbKyAP+EZEhV3OQKiU3bJ aRJXy4ahdue6woeSUuMPRwbQYFP30WUEzt13TODnW6ftLA+80/WWlYVIKH2tXHEQX53IaOHmizM PHv/fbk3CtY7l0C5/bVIQyO6d+cAcYnSv+08AsYER87+9m8DnSVI5jrLIA5wKbUUW43Ju3jxE5C /OOQ3TirSOYTG4B9RrkMcdvAdjUZ9xMOubVZYXo/YiYrctb/6mA7a+B9Vcpyr025eTsK51uwJ7b rfyNhy8Z21EhE4m4eebCUFtAwRxshjHXAkDKB20wUNkfhb89dAoCm0yd9ww28E9MnF6BFkGuuNj x5bK63BMXNH8FJTglA9Qz2gwPV54ve2cA== X-Received: by 2002:a17:902:ea04:b0:2aa:d5e5:b12d with SMTP id d9443c01a7336-2ad744eec7bmr63336785ad.27.1771860240205; Mon, 23 Feb 2026 07:24:00 -0800 (PST) Received: from [192.168.1.38] ([103.165.20.93]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad75027b0asm84344745ad.67.2026.02.23.07.23.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Feb 2026 07:23:58 -0800 (PST) Message-ID: <4fa1f4f6-3abe-4acf-938d-abc49a14b6aa@gmail.com> Date: Mon, 23 Feb 2026 20:53:54 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] staging: rtl8723bs: properly validate the data in rtw_get_ie_ex() To: Greg Kroah-Hartman , linux-staging@lists.linux.dev Cc: linux-kernel@vger.kernel.org, stable References: <2026022336-arrange-footwork-6e54@gregkh> Content-Language: en-US From: Navaneeth K In-Reply-To: <2026022336-arrange-footwork-6e54@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I don't have the physical RTL8723BS hardware on hand anymore to test a live connection, but I was able to verify your logic thoroughly in user-space. To be absolutely sure, I extracted both the old and patched functions into a standalone C harness and ran them through Asan and AFL++. Feeding a crafted 5-byte allocation(with a lying length byte) to the old code predictably triggered a 47-byte heap-buffer-overflow right at the memcpy. Against your patched code, I ran that same payload along with 20 other edge-case tests (1-byte buffers, empty bodies, OUI boundary mismatches, etc.). It cleanly rejected all of them with zero ASan errors. I also compiled the patched function as an AFL++ target and let it freely mutate the EID, length, and body bytes. After over 100,000 executions, it reported 0 crashes and 0 hangs. The logic is definitely solid. Changing the loop guard to "while (cnt + 2 <= in_len)" guarantees we always have at least 2 bytes before we touch the EID and length. Reading ie_len once and explicitly checking if it exceeds in_len completely stops the memcpy from reading past the end of the allocation. I have the raw ASan logs, AFL stats, and the C test harnesses saved if needed!. Tested-by: Navaneeth K Reviewed-by: Navaneeth K On 23-02-2026 19:01, Greg Kroah-Hartman wrote: > Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds > read in rtw_get_ie() parser"), we don't trust the data in the frame so > we should check the length better before acting on it > > Cc: Navaneeth K > Cc: stable > Assisted-by: gkh_clanker_2000 > Signed-off-by: Greg Kroah-Hartman > --- > Navaneeth, any chance you can test this or at least verify my logic is > correct here? I got a "hit" from a tool that the work you did in your > commit also needs to be done here, and I _think_ I got it right but do > not have the hardware to test this with at all. Thanks! > > drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c > index 6cf217e21593..3e2b5e6b07f9 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c > +++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c > @@ -186,20 +186,25 @@ u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui, u8 oui_len, u8 *ie, u > > cnt = 0; > > - while (cnt < in_len) { > + while (cnt + 2 <= in_len) { > + u8 ie_len = in_ie[cnt + 1]; > + > + if (cnt + 2 + ie_len > in_len) > + break; > + > if (eid == in_ie[cnt] > - && (!oui || !memcmp(&in_ie[cnt+2], oui, oui_len))) { > + && (!oui || (ie_len >= oui_len && !memcmp(&in_ie[cnt + 2], oui, oui_len)))) { > target_ie = &in_ie[cnt]; > > if (ie) > - memcpy(ie, &in_ie[cnt], in_ie[cnt+1]+2); > + memcpy(ie, &in_ie[cnt], ie_len + 2); > > if (ielen) > - *ielen = in_ie[cnt+1]+2; > + *ielen = ie_len + 2; > > break; > } > - cnt += in_ie[cnt+1]+2; /* goto next */ > + cnt += ie_len + 2; /* goto next */ > } > > return target_ie;