From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 895373112A5 for ; Wed, 12 Aug 2026 19:06:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786561570; cv=none; b=IgRwj5WmY7HIwjG6p39J2UD3GZF1/vr1qbG/HmYsXCQLWgh2QobiM+C3i7Xpj07OlQI53BgNEfYk/0qhUv3gwbqAAkbTnNo7RQbH7IKQJwg6fiiUnY5r+4bXy5FyFh6N43JenglIJJleDbcrWo3IBbAYvKsJ50xTP2+XAKjpEKY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786561570; c=relaxed/simple; bh=T3sPnoq0RTs0uG8HPlVWHRGrVSNIKWFyaLvT/6yrFPQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h3xMgDcxeXeNajXP3oupEC/uktd6WMSyJuK2sc/ir2DRV+smdrcC1p+Ftr4wpjulBOivYUSQAQFWL6dfcdhvvDV/qWXYFav+SHyyb4OwkNss5KrQM5Cb+c16+UFcilQbEAe1VUkLaH9whLksqDCJfePVU3wykfM1OCzISY3YsPY= 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=XXQC3PK3; arc=none smtp.client-ip=209.85.128.48 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="XXQC3PK3" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-495757ccbc1so11680345e9.2 for ; Wed, 12 Aug 2026 12:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786561567; x=1787166367; 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:content-type; bh=jw5hnegB1m/L5wmsBBcHwaBQGgRjAN6McFTUJSuZSpc=; b=XXQC3PK3c6w2rexY4dXeMslJdD5bFihF0Bx3NXelxugdDn0Yu5z9yK5IS0Im3OXpcQ qLQTSAUGUl0SUAkS05b7yqbd0j1PKt44rGDk4FkFTuu+qJCW2cZx5sQyT+6au8UZlN3A xth5o+Lx9YGdfl3bszCwMGZ8TSqiecsCaGapwUULvLYoXVIFHRtMcOIw7IwmSBYwxrbR S7qfYsgqXnTjvLpBo9zDynZwh8vn9VobxQYFBX9017/aL9bxyL5xufBsRwhOCyk00/L9 V3bpjKuI2WlDbIPL3SRaGy/0/3vhwOCZmJWvB+DiLQh+yZn0YEIxDFgZ7o5PK4C3PrOH XzPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786561567; x=1787166367; 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:content-type; bh=jw5hnegB1m/L5wmsBBcHwaBQGgRjAN6McFTUJSuZSpc=; b=YFS2WzZNEAbPqEp7jC7B3y4+FkskIwRjFm6eKobpNFpUSxMuPzJ4WllnXnr9L7B5SG sf+xRo42pvp1EO77R1wsBZ4TnElsZB99BZtkzXXMEC7EzFyuz32/Nno94SkTYV//aLAy m3IrzhJS0dcHil+BwwJ92ARAXcpJJ+RGCYO362XBDQtotV9TRE9n24P0l0eGFaUVb9qm E08NyVnWAqyBydELsXdmyPhKu2xEIT8GDKuVehl6jsLxsojxrnCw4GVsefqT+iHc9I0q cmWIgVlIGioLN1uczR1/FP/PIjpyFJlsjLFkuxtsi0QavZwzijd/wsvJUpJmCABWid1B kucQ== X-Forwarded-Encrypted: i=1; AHgh+Ron1XiK7f4EaNgfDDTPoOEYymq9fE9Y8z5S+UY2JkU/+bjJEoZFFUBffdhTRFOpLvha5af3er0ivuBb6ec=@vger.kernel.org X-Gm-Message-State: AOJu0YzCqFOUnZSpqmYzv1/anVjpmv2nRAuSbZHTJCHTgkinxooJ1bFe 2/1ahchRslqaEcS3B25Dr6T6g5CbrZniAyQ4tmkixIY7oRdiOJncuH/n X-Gm-Gg: AR+sD13u7AhseOXGzmFVITCOAqAG8jXIyYhjpXEQZiIIzkCVB8MJ9bjabqWUa05rY/T cL56XvJXXn7aT2vZni/85E3gQ4hx20AsmfB+dPvyRkFqwyxJ0JzyZvej7CnM/aizB71AH25O+k4 8NKHYetjgof+IgyneyZyFwqRQOQQvkA95dzdCxLcP2bR3tLFGRuFxeua7ExhN8Go+5f9fqCOSam CloC8/M1G/IP0fTIemV1PfD0fHSXEBk2Vf5ezZ1uLABarXmZIwbxPRUwXyw36C+RnPEyBGouOjK vb+PFGmRV0woN/hXmwd/BbDo5TfVFFyCz4cUscY2VRrfdvZwv6sCONE/SH5fmehdsg9IjVDCqyD KbujD3U/y7rHSS2brmxnSUKE80RwQKtu3x7wBrzQ7tBeshyBSCpN1GqLdnWIng6G35Yq5gkDPpv 7cY/I4uBrwm6l8AJ1x4nvHfBFSq7pgP6NQvf5Pt16wPeXGG5W1lITFpIVBWcgcu6YN3w6J+/ICc GLqRz2DQzoXZvVbcAsbvEfknUcTybU21Si4NTVpdHAEtiZG61DvYAniGDFdjJ4JQcVaeVM9RQGq iZY+Wg== X-Received: by 2002:a05:600c:46c6:b0:498:ee7:e407 with SMTP id 5b1f17b1804b1-4997c1649f5mr87009305e9.17.1786561566686; Wed, 12 Aug 2026 12:06:06 -0700 (PDT) Received: from Mac.home ([95.35.242.1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48150d5eb2csm9179875f8f.30.2026.08.12.12.06.04 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 12 Aug 2026 12:06:06 -0700 (PDT) From: Shmulik Cohen To: stas.yakovlev@gmail.com Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Shmulik Cohen Subject: [PATCH 3/3] wifi: ipw2x00: bound management frame length to the receive buffer Date: Wed, 12 Aug 2026 22:04:12 +0300 Message-ID: <20260812190412.18333-4-anuk909@gmail.com> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260812190412.18333-1-anuk909@gmail.com> References: <20260812190412.18333-1-anuk909@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: 8bit Both management receive paths establish a lower bound on the frame length and no upper bound, even though the length originates from the device. ipw2100_corruption_check() returns 0 without inspecting frame_size for management frames, and __ipw2100_rx_process() only rejects a frame smaller than the three-address header, so any reported size up to the u32 limit reaches libipw_rx_mgt() against a receive allocation of IPW_RX_NIC_BUFFER_LENGTH bytes. Check frame_size itself rather than stats.len, which is a u16: a size of 65566 truncates to 30 on assignment and would pass a check made afterwards. ipw_rx() likewise only rejects a frame shorter than the header length. Bound it against the DMA mapped receive buffer. The size passed to alloc_skb() is rounded up by the allocator, so skb_tailroom() can exceed IPW_RX_BUF_SIZE and is not a usable bound here; the existing uses of that idiom in the data paths are too permissive for the same reason. libipw then hands the remainder to libipw_parse_info_param(), which walks information elements for as long as the length allows, so an over-long reported length reads past the receive buffer without any wraparound being involved. The length is device-reported, so per Documentation/process/threat-model.rst this is a robustness fix rather than a vulnerability. Found by an AI-assisted review of length arithmetic in management frame parsers. Compile-tested only for these two hunks; I do not have the hardware, so they are not tested on a real device. Assisted-by: Claude:claude-opus-5 Signed-off-by: Shmulik Cohen --- drivers/net/wireless/intel/ipw2x00/ipw2100.c | 4 +++- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 9 +++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c index 2b8a23865bfb..43b4e432956b 100644 --- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c +++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c @@ -2712,7 +2712,9 @@ static void __ipw2100_rx_process(struct ipw2100_priv *priv) break; } #endif - if (stats.len < sizeof(struct libipw_hdr_3addr)) + if (sq->drv[i].frame_size < + sizeof(struct libipw_hdr_3addr) || + sq->drv[i].frame_size > IPW_RX_NIC_BUFFER_LENGTH) break; switch (WLAN_FC_GET_TYPE(le16_to_cpu(u->rx_data.header.frame_ctl))) { case IEEE80211_FTYPE_MGMT: diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c index 4bc9bb406e8e..8249d493ee22 100644 --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c @@ -8322,6 +8322,15 @@ static void ipw_rx(struct ipw_priv *priv) break; } + if (unlikely(le16_to_cpu(pkt->u.frame.length) > + IPW_RX_BUF_SIZE - + IPW_RX_FRAME_SIZE)) { + IPW_DEBUG_DROP("Received oversized packet. Dropping.\n"); + priv->net_dev->stats.rx_errors++; + priv->wstats.discard.misc++; + break; + } + switch (WLAN_FC_GET_TYPE (le16_to_cpu(header->frame_ctl))) { -- 2.50.1 (Apple Git-155)