From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f180.google.com (mail-dy1-f180.google.com [74.125.82.180]) (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 2917E2D592C for ; Wed, 22 Apr 2026 19:54:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776887661; cv=none; b=ZLGNf1rXHdXGjSJ6GLp5QP4L4OnLJ90yPg8Qgzc03MCAb/8Mdh0itbxNRwp85PiNfP0Jn5mwiO99gNy6Qk8/FEOQWiPYryy10/AE8GhE7tLXA+eXkOP0VeFlM6Pe6R0fgSxjgEkQfVNbNGeQJI9PJbjWblFWka14mZ1Ww7Hod9A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776887661; c=relaxed/simple; bh=e5IZu42mb7nV0X3l1RkdEY/DI3U71KqYU4Q6BEfv5m8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mwE3l8kRhy9lXY+W9qsXoXmUdABHbmaTgQuOQCnbAmo0SMEFWeX7KJ9HTV1nm3D6eOibrNnJ638lRI5Vchf78My/8sivzJRJ5Kc8ADFh14iQvO5cGpl4HhYLyC5ut4gbfB+NcIlj4mTFzoyOMgBIFCINcUng6py/EaXcVZ0PSOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=A4J09eGF; arc=none smtp.client-ip=74.125.82.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="A4J09eGF" Received: by mail-dy1-f180.google.com with SMTP id 5a478bee46e88-2c156c4a9efso8039943eec.1 for ; Wed, 22 Apr 2026 12:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1776887659; x=1777492459; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9cMyiwH+fmvU5XTrh+FUXRhUtV8/4w1QLlRxNETTXXI=; b=A4J09eGFAqnz63ABNAiXa7NKyzwcjsH2r+ipRJHU4VIt8FjRnwE++bFPyqTf4M3am/ 14xZKX8Nd9vtQHmlD/rnt9HUtLriTU3jbjthr2OItt6hpeXUTmbsXFRWhwj4wDfIRO+z SCvpdug1hx5QjpKgyZTnd9v75jGSOS7oJ+4HA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776887659; x=1777492459; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9cMyiwH+fmvU5XTrh+FUXRhUtV8/4w1QLlRxNETTXXI=; b=SsRkEqRjCe1uF0KkNblxcY5287v57udOUMgjYyEsbe1OX2oQE7MP8IoeADJzJGkZwd Wd1BSWAS1oKQm4pgx5RtNsCMum/PpsCg3+uPP5nMMP64swyBhr0HdH87ijXhasyQlTkb 9gnhF/CV6xy+NcfQWXEOp3LbP96xfVPQTLittDt5kEDLJN81bzTv5EOgZsJBZOqQDtZI 10YX4/n8mQE8qjbAY3c7QH8FZBPU4CqQbn2g7UMng0wNLcppz0fsl+TKzi+HNfszAXG9 lVT/u/zJQfOFGpitw8Zncidr3B7PJz7L1/Y8bYexJZdVwLmRmWzeSrjaPdAyMvRlntcX VFpw== X-Forwarded-Encrypted: i=1; AFNElJ/KsiyCNceyybhn8vvWduZHYKth+MMGV74iPqJ+JKpVCCMpg+HVvVwgZlzNWnFerYdY9/0g1HaRFT4kDzI=@vger.kernel.org X-Gm-Message-State: AOJu0YzkKizTxL+pxXLsCyxhmFxH+k1wYfZq4PapUXjPBVomYdpfcPFE 705Ww4PUEDPQYyv1jZDAJZAxlGJmibVRDZXb/EKo/B5cKfVx0MYfCwRtZf5RZowoyQ== X-Gm-Gg: AeBDiesN9awijMJ6QVAO4NoZFK0oMgWkYX6GmuCKQyjaYXlaCYy9BXPyUtYjY3c/l3b oG2E4tSjkmMb5KG0/k/t6usfIl61T8jCeOWv0SJHkBA/miR11vlCc5JDDRNIQfaG2oMYWueHU5u JMlhWsKjvQGif7vAytFsFTz+xLGY09sBBf73AU1e585OgI6Vjdgyzxv+npQdgat0XdJdMg2BcgJ ifMCQf14kVzJ8mABe6fjKTv+jTzSk1IRSSkYPlbWy5SHTe1xEsqbymq+d3zV3SQX3Rk/xR+EXzD RW+rDH6MJ+WJFtLiO9ZOncjJuSWXP60JAvk4A1e2aigpVdlQsz+yYpGSyXnR8l2wCqVQf7tlbLK 9TzfaGH21mfQfzk8AFZNQmGGIPyqyjuziQabhu/3puiFgN5TQw6QBGRegyNKqdfMYi89OlEMUpd CzHccaQIBxSXJ3Byy2y1/X9x61ciOJymqVYr19fN0SAfUFrZOyh7eZhp9yPsXdF8rlLAwaxZ9g X-Received: by 2002:a05:693c:2b04:b0:2d8:8c38:8cec with SMTP id 5a478bee46e88-2e464eaa23emr12092785eec.2.1776887659239; Wed, 22 Apr 2026 12:54:19 -0700 (PDT) Received: from localhost ([2a00:79e0:2e7c:8:e136:eb5d:6ed2:47d5]) by smtp.gmail.com with UTF8SMTPSA id 5a478bee46e88-2e53d8aed43sm24463386eec.26.2026.04.22.12.54.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2026 12:54:18 -0700 (PDT) Date: Wed, 22 Apr 2026 12:54:16 -0700 From: Brian Norris To: Johannes Berg Cc: Tristan Madani , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Tristan Madani Subject: Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response Message-ID: References: <20260421134938.331334-1-tristmd@gmail.com> <20260421134938.331334-4-tristmd@gmail.com> <2e20cb23d2d156963c2b687c4c51635e5eec2c7c.camel@sipsolutions.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e20cb23d2d156963c2b687c4c51635e5eec2c7c.camel@sipsolutions.net> On Wed, Apr 22, 2026 at 09:12:11PM +0200, Johannes Berg wrote: > On Wed, 2026-04-22 at 11:26 -0700, Brian Norris wrote: > > > > > + u16 resp_size = le16_to_cpu(resp->size); > > > + u16 count = le16_to_cpu(sta_list->sta_count); > > > + u16 max_count; > > > > > > - for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) { > > > + if (resp_size < sizeof(*resp) - sizeof(resp->params) + sizeof(*sta_list)) > > > + return -EINVAL; > > > + max_count = (resp_size - sizeof(*resp) + sizeof(resp->params) - > > > + sizeof(*sta_list)) / sizeof(*sta_info); > > > > The repeated arithmetic is a bit weird, but I'm not sure if it'd > > actually be better to stash it in its own variable. Seems good enough I > > suppose. > > I think it might be simpler if instead trying to limit: > > > > + count = min(count, max_count); > > it'd just check the needed length based on the given count, and reject > anything above that? That might be better. > Also, the whole sizeof(*resp) - sizeof(resp->params) etc. shouldn't be > there, that should just be > > offsetofend(resp, sta_list.tlv) TIL. I don't recall seeing that macro before. Or at least, I didn't know it well enough to recommend it. > and then suddenly it becomes _way_ simpler: > > if (resp_size < offsetofend(resp, sta_list.tlv)) > return -EINVAL; > if (resp_size < offsetofend(resp, sta_list.tlv) + > sizeof(*sta_info) * le16_to_cpu(sta_.list->sta_count)) > return -EINVAL; Looks good to me. > But regardless, I question the sanity of checking the size against the > size the firmware said the whole thing was going to be, rather than > checking against the actual buffer size ... Admittedly, I get lost in this driver sometimes... ...but I think you have a very good point. AFAICT, we never do anything to check the size of adapter->curr_cmd->resp_skb. We generally assume it's big enough to fit 'struct host_cmd_ds_command' (since we allocate it ourselves). But we don't ever go back to check these dynamically-sized fields don't overflow it. Brian