From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 B5490273D6D for ; Sun, 21 Jun 2026 08:17:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782029831; cv=none; b=dsR3VqtmO7IzHI+eBxAxf40CQhFMKMbVAnOukhShSPXBtcDPbDPRbvnGbCXlk1eAtY3DU9ZU0B9qpWcfWzs0vAljYzVO3SlSJE0O9EwXnoe6W+LOjfXRDDMk0W+CnaQK0SJkxVehoBT8yVMBXrvNTpkqlSgKc7n/5EeJJ72/iHU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782029831; c=relaxed/simple; bh=gmAnStZ8FyZx2TvUXcP7lf5VWLG1jbjrk1AXQ6cghxY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r/0xqkik+0tshH/T/feC4ktLhnC8cd/y4RLvJgFholp6EHcosrVBvyyfAuYKOK1VGCWjlmpEqIogHbAoxYTzdSbgJYfBRs7WLV38OFSdRqKmpsvma5M7mzpNgMWxaPZ+u8Xxp+Yb8dz+uDEhklgAKbU8tcGdzaQYZtZwscgHGQs= 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=IGIPkLRA; arc=none smtp.client-ip=209.85.221.49 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="IGIPkLRA" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-462ebd5d37dso3434497f8f.1 for ; Sun, 21 Jun 2026 01:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782029828; x=1782634628; 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=xv8167L13PZ/JQZMUsJG/gGl8WHuMlNvKPvQHLdring=; b=IGIPkLRAKULhs6PPvfp54vjEI13GYwoqM7T6hUu9c0YfkBdgXqV693kxtcBpzMOeVs bTekNvAF2IBMV9XKtLoR3vaC+/z9rtRv0dpmmxKW/zb6eDtNH/oJcvCuyQgaBhVVJqbZ B22I/IMTgIocYy5xpss9U4Uq+j2D0iNk2opMm1kfM4A4wpmFZWOVIl4Zfp4QR3e62yxl At+XCDFbvoG/ZXs+VlJo2Ytqq+J0P1kwKm7brhY1JgFcBRi/4CZ2sb/TeIbOZ7ZJl7jN ZPrdqMcakXTSXomAF0FBoxsFpUdk/zkmJUDFZBHh4jdSrG2RbvVDDoxhIzyXA9DmSEed uCXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782029828; x=1782634628; 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=xv8167L13PZ/JQZMUsJG/gGl8WHuMlNvKPvQHLdring=; b=HkgUnf0DRQnIvOubAX7VhcLpxFFgHQh+mgZsfspmXiMvJHakaw3Okkc+jIi+LtqUpc jxqsbajOOpnAjUZ7g+aenvdMkHr/w/5GrI5q8W2aBcVnTRVdwJcbJOR1K00dSRgDXlVu nM3wl8/ycPT713uZTbtr5fzs+5aq+7KU/6oIm/tVtk9xPU4sdpp/NvetPBYQkjQ5UJQT XlRWZACoClN7vejHrvkMSFWHwqdD5qH7ooIuDfTAFZ0BPpLxwZsK0njA1xvxf39ttGIP uizGHGzwWL9MEtA0ZDvH3GNSPncZoWkFB7Gavd5C5rH2vpb1ZwKVREk08DcK6EaZgTlC 4hOQ== X-Forwarded-Encrypted: i=1; AHgh+RrLdOrkXHxPOhUr7f9pnSdtcpNH27f0w9pI7A5xl8La/vARjJS/uA7HAe+NAYkAkeKoUiKYFgflqNdlCC0=@vger.kernel.org X-Gm-Message-State: AOJu0YxU0grrbxz6tMzGWJiBTjp4Vo3+gYkOsSjBxOE6pMYDKzkzcdx+ LbJrb+F6FFP7qiWUTVUe1DVbiD0UNfFlh8le9e1+7dwqOMWPAGrtkFcW X-Gm-Gg: AfdE7cmTzZeQFYo8h+9HCCfTagEuN5IGZApbrlXvkF56okbex44dp6RByM6mVPOtoj6 S3JFsRK/f+Fpdm6qQyUYnrqhJa6SAeAVynL2ePPY/jVt/WO5VD2oPA8sgpMr5MblPlwLWxu/dfE s/3WXDoDUXxf/zitSOcyAv0+ejAwG+Egt9cr5bim5Oz3AAmf1jPBSueD/Ilq0EKosqOrbHU2Wv3 sOoEBpgXhCs2ZlXzY7PDfNb5YcSzrEAv1UWXSxGfWBk0ioysRh3+llUvdE4WBEGcDayF8C5LNkW JwMIlQAyj8HsjlTKawhg5hgAghK92jtH3Mei+aZbzvV09gNrFQutzpcB85oywViqWHvv6iwtnzx 5WXmJ+4YY+csJUKAtOFoQWxX4OEt378J1wiSOpfxLkC2eU/8svIGtnMV1s0jiJeG2Ih8rW+PcKR PB39t6h6LzNBRShi5PL7Vdrb2v74uS8phmT+RKIIgaFFo07Xk/XfM6tUHDjCan+XPua/k+ryczx LoYelxOIc4= X-Received: by 2002:adf:fc8c:0:b0:43f:e934:50ac with SMTP id ffacd0b85a97d-464fff62e1emr13858379f8f.7.1782029828081; Sun, 21 Jun 2026 01:17:08 -0700 (PDT) Received: from shift (p200300d5ff229f0050f496fffe46beef.dip0.t-ipconnect.de. [2003:d5:ff22:9f00:50f4:96ff:fe46:beef]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-466648c5ddbsm15917211f8f.12.2026.06.21.01.17.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2026 01:17:07 -0700 (PDT) Received: from localhost ([127.0.0.1]) by shift.daheim with esmtp (Exim 4.99.4) (envelope-from ) id 1wbDH4-000000002RS-40So; Sun, 21 Jun 2026 10:17:06 +0200 Message-ID: Date: Sun, 21 Jun 2026 10:17:06 +0200 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] wifi: carl9170: clamp command response copy to the read buffer size To: Doruk Tan Ozturk , Christian Lamparter , Johannes Berg , Jeff Johnson , kartikey406@gmail.com, Tristan Madani Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260619224818.90751-1-doruk@0sec.ai> Content-Language: de-DE, en-US From: Christian Lamparter In-Reply-To: <20260619224818.90751-1-doruk@0sec.ai> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 6/20/26 12:48 AM, Doruk Tan Ozturk wrote: > carl9170_cmd_callback() copies len - 4 bytes from the device command > response into ar->readbuf, which was allocated by the caller with > ar->readlen bytes. When the firmware/device returns a response whose > payload is larger than the requested ar->readlen, the mismatch is only > logged (and the device is restarted via carl9170_restart()); the code > then still performs the full-length memcpy(), writing past the end of > ar->readbuf -- an out-of-bounds write driven by an attacker-controlled > (malicious/compromised) carl9170 USB device. > > Clamp the copy to ar->readlen so an over-sized response can never write > past the caller's buffer. A response that fails the length check is > already discarded by the restart, so copying only the buffer-sized > prefix changes nothing for the valid path. This is contested territory. Original patch (as part of a series is from Tristan Madani) Yes, I do think each came up with the patch individually. But I have no idea how this works with three authors / tools? Does anyone? I don't think this will get any better though. > Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com > Tested-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac > Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") > Cc: stable@vger.kernel.org > Signed-off-by: Doruk Tan Ozturk > --- > Verified with syzbot via "#syz test" against the public C reproducer > (Tested-by above); I do not have carl9170 hardware locally. > > drivers/net/wireless/ath/carl9170/rx.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c > index 908c4c8..897e682 100644 > --- a/drivers/net/wireless/ath/carl9170/rx.c > +++ b/drivers/net/wireless/ath/carl9170/rx.c > @@ -150,7 +150,8 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer) > spin_lock(&ar->cmd_lock); > if (ar->readbuf) { > if (len >= 4) > - memcpy(ar->readbuf, buffer + 4, len - 4); > + memcpy(ar->readbuf, buffer + 4, > + min_t(unsigned int, len - 4, ar->readlen)); > > ar->readbuf = NULL; > } Regards, Christian