From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 6F41B36728D for ; Wed, 12 Aug 2026 19:05:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786561558; cv=none; b=Qeg+ksnA8E25KHnrMrfGh4HYzXNaCIO+9xm0IIXVx73BpalceQV1E5k5kaAjLWsqdpWpC7A8ehCKSOpgiSmPAYq8SNv5xFu2XQVvZqN9JP5DfKUj59kg3ut5FceRG8LqkYLR+VgUI7n9AnrtEs6MMEshCy/1XXY6C1L4Vn+eURw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786561558; c=relaxed/simple; bh=T6g45jeUAECgXRrwnm3vMiXwhhpytNHNv6gdJIOVCIM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=eT9o4hPMaNPp7vsUlVggmFfh7704P+wiIbVaw9iE1z9VExASE150egqCrwLrzqdT164my8oVpuIgJM/+3Pg/HWbPjQCGiNoA7ccRlZGIzhzOJoLYZlgQT/zIUiQh+e/MOZV4AgjhgHJBVdoToJnjo0rXdI6TUV32wfcN5dsDZT8= 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=KlK4TUVI; arc=none smtp.client-ip=209.85.221.47 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="KlK4TUVI" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-47fde295992so163385f8f.0 for ; Wed, 12 Aug 2026 12:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786561551; x=1787166351; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=OneEcsd3WS4X/wyCuCDPzIsiDC1m3+a/nq+CgJxUeKk=; b=KlK4TUVII0q9tOSDRCukGT4oYq8K09DcaogxRDviWkvlhN6E4iuF911E5MpuOMtn1a UNgcryvl25f5vpDvH0mwuIdwGlusM+0afQfwINWKLkDZi0yoi32elZAHL9zLCfBy/2a0 edVV3H0qLYh0papRrfh6DRqcx1Su0KOhKnm+gOVADVlBg0ve/WoV/e0OL+dQN6/x+K1/ 4cRG5bbUzUVoNg6rEb7PXz/nAxDqL6ErakyYdkz5A9NalrhNXWR7mTN7v8xu01kSIJ70 a7m0CEqq5MCYgSivvIlcoucfUCy76eRtX/RIEytjsvGAcez81SZ+6GXK8+l/JH5tgQUY YDgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786561551; x=1787166351; h=content-transfer-encoding:mime-version: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=OneEcsd3WS4X/wyCuCDPzIsiDC1m3+a/nq+CgJxUeKk=; b=Q0uCZKV4Mq54rpU4V5hEQ4ZzMc8WosuAEHSGbNfKWlZeXQiojFzmYK3QuACbCspypj cSRLjybRWwg3kc5cR8cn13l7+xML6FNq6VErgUK9OR9ihRJhe95tr6hmzO0hgOeumTOt 5CATUNDopdckA/nFG06SnYc7oA9CTJkEY3BD4fu86E92aD7mtXtpIV+FaIGAAfYgDKFW L/EsNsqNIibX1FVk0Ac4UzdkCPcSnHfAVEsOkTf0KLdgm77PmAGcgRPVUiZ9Ri29TEDJ aLFujxWJwe7FHY8EzAN4N31O4zDO33IGL3ALY7vKupIkfzaaJjxy68KjDFXWl8rSfs86 yoag== X-Forwarded-Encrypted: i=1; AHgh+RoCITZpPGvPg2Bo3/WHf52qG3Xr59e3Rkq0c5OeP8kwMgDhZQtQF46BezHtYXdVAgwKQcG8aSg6wSLuDdo=@vger.kernel.org X-Gm-Message-State: AOJu0YwCd9WRWfYg5nR3gijxh6EbUjG/McBkDSMTrcrkVRIblO0OL9xx ab5rRjqhvRfzwwrFIk0Qsns7Ud9BAc0uSJ/AFcdgcezayuiOoUmg5SsH X-Gm-Gg: AR+sD11rp6a/3W8NPdkaYDuoGPhCm0FCY2h2D46UZZvJNBX2K2C6WR7Zvy2p2LqyOCA imsDk3gjzTxN7h4KmQ88YFLpYdXXSH/V1UcgLuo8cq9sjt81eVMvd7DaLcztzum6AgwZIbFTi0c h8/T+9AohJk++VgkmJrY1peJ3FLKqznqJQGBmMLnNheKDe87cT6SJJVvhcXbPVtxl8icoCibvEB aUYZxTtf1rTbT0Vs1zkpU7x2tSQtDhqznwHwiQs/6NvyqNdJQsgAbYoT7JFeHSby6x5/lzsWRCx UPJ7LnaOHjtvjzS7TJWw5fCwAZh8y4sn5xYvBfR+f5WyKoifJcYellgiK/8ncH10NtVWVeFfLkk NsQFbQ2Pbgvr9jKNRlNinE2fmjNeCvgkdcHlrywn9bC4pqyBagbeu5KF7N07vzTQtY0RrXmXGGx AI7Q8in6KQzXP80MyxrH7LQbW3Bn16NhzUJsE889MHabWgoYoqdrw6adRaWAwdOSmtLHQgzA5ni LWPrk5nfWUbhSohuRO5262qVURgmrS8gE1AvTgorobeAj9bE6om/ePXXkYdGOhdBqxJoez/4e1K DYl8QQ== X-Received: by 2002:a5d:58cb:0:b0:47f:8554:a341 with SMTP id ffacd0b85a97d-48158e95fa6mr1891878f8f.13.1786561551185; Wed, 12 Aug 2026 12:05:51 -0700 (PDT) Received: from Mac.home ([95.35.242.1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48150d5eb2csm9179875f8f.30.2026.08.12.12.05.49 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 12 Aug 2026 12:05:50 -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 0/3] wifi: ipw2x00: fix management frame length handling Date: Wed, 12 Aug 2026 22:04:09 +0300 Message-ID: <20260812190412.18333-1-anuk909@gmail.com> X-Mailer: git-send-email 2.51.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The libipw management receive helpers derive the information element length by subtracting a fixed structure size from the reported frame length: stats->len - sizeof(*beacon) /* libipw_rx.c:1300 */ stats->len - sizeof(*frame) /* libipw_rx.c:1240 */ stats->len is a u16 and sizeof() has type size_t, so each subtraction is evaluated as size_t and wraps instead of going negative. Truncated to the u16 length parameter of libipw_parse_info_param(), a frame shorter than its own fixed fields becomes a length near 64 KiB, and the parser walks the receive buffer as if it held that many bytes of information elements. Patches 1 and 2 add the missing checks in libipw itself, so neither handler touches its fixed fields or derives an element length from a frame too short to contain them, whatever the caller passes. Patch 3 bounds the reported length from above in both drivers. Neither management path had an upper bound: ipw2100_corruption_check() does not inspect frame_size for management frames, and ipw_rx() only rejects a frame shorter than the header length. All of the lengths involved are reported by the device, so per Documentation/process/threat-model.rst this series is a set of robustness fixes rather than a vulnerability report. I am not claiming otherwise, and I have no evidence that any particular firmware reports a management frame length below the fixed fields; the checks are cheap and the arithmetic is wrong regardless of who supplies the length. Verification ============ Built and run on arm64 under QEMU at f5bbbfec59b4e ("Merge tag 'probes-fixes-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/ git/trace/linux-trace") with CONFIG_IPW2100=y, CONFIG_LIBIPW=y, CONFIG_KUNIT=y, CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y and CONFIG_KALLSYMS_ALL=y. Before patches 1 and 2, KUnit cases that call the two handlers with a 2340 byte allocation, which is IPW_RX_NIC_BUFFER_LENGTH, and a reported length of 24 report: BUG: KASAN: slab-out-of-bounds in libipw_parse_info_param+0x100/0xee0 Read of size 1 at addr ffff0000021a092e by task kunit_try_catch/33 libipw_parse_info_param+0x100/0xee0 libipw_process_probe_response+0x354/0xc08 The buggy address is located 10 bytes to the right of allocated 2340-byte region [ffff0000021a0000, ffff0000021a0924) BUG: KASAN: slab-out-of-bounds in libipw_parse_info_param+0x100/0xee0 libipw_parse_info_param+0x100/0xee0 libipw_handle_assoc_resp+0x2e8/0x3e4 The buggy address is located 4 bytes to the right of allocated 2340-byte region After patches 1 and 2 both cases pass under KASAN. The KUnit cases exercise static functions and are not proposed for merging, so they are not included here; I can send them on request. Patch 3 is compile-tested only. Both drivers and CONFIG_IPW2200_QOS were enabled and the driver directory rebuilt at W=1 with no new warnings relative to the unpatched tree. What was not done ================= I do not have ipw2100 or ipw2200 hardware, so nothing here is tested on a real device, and patch 3 in particular has no runtime test. The reproducers are KUnit cases that call the handlers directly with the lengths the drivers can pass them. An unrelated observation while tracing these paths, in case it is of interest: the CONFIG_IPW2200_QOS block in ipw_rx_notification() (ipw2200.c:4470) looks unreachable. It is entered only under case CMAS_ASSOCIATED, which establishes that notif->u.raw[0] is the state byte, value 12, and it then tests IPW_GET_PACKET_STYPE(¬if->u.raw) against IEEE80211_STYPE_ASSOC_RESP. That masks the first byte with 0x00f0, giving 0x0000 rather than 0x0010, so the two predicates are mutually exclusive and libipw_rx_mgt() is never called there. The frame and its length look like they were meant to start after the state byte. I have not sent a patch for it because I cannot test the intended behaviour without the hardware. Tooling ======= Per Documentation/process/generated-content.rst: the defects were found with AI assistance (Claude, claude-opus-5) during a review of length arithmetic in kernel management frame parsers, prompted to look for subtractions of a fixed header size from an unvalidated on-the-wire length. The tool identified the call sites and the truncation, drafted these patches and the KUnit cases, and ran the KASAN and W=1 builds. A second model was used adversarially to attack the result; it refuted an earlier fourth patch and an earlier version of patch 3, both of which were dropped, and every remaining claim was rechecked against the source by hand. checkpatch.pl --strict reports no errors, warnings or checks on any patch in the series. Shmulik Cohen (3): wifi: libipw: reject too-short beacon and probe responses wifi: libipw: reject too-short association responses wifi: ipw2x00: bound management frame length to the receive buffer drivers/net/wireless/intel/ipw2x00/ipw2100.c | 4 +++- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 9 +++++++++ drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 6 ++++++ 3 files changed, 18 insertions(+), 1 deletion(-) -- 2.50.1 (Apple Git-155)