From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 CFCBC275870 for ; Sun, 21 Jun 2026 08:17:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782029832; cv=none; b=Rk439yESaXVxdl9DwpA3hfOZaJ/zTXl6kzQryeqj23FtTAqyAP4ffYCqvRGvw7QrLvLVW7kykoOfnm5RAUfUjkUmquz2z6Xrbe355h+PS+5RsRdtw0NAl0UwmxvPqW4d2CAhAY0tRCAgn0JOTbzwO4xoV6Hz/HvtcQnPwi/hhQ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782029832; c=relaxed/simple; bh=gmAnStZ8FyZx2TvUXcP7lf5VWLG1jbjrk1AXQ6cghxY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RipBf1KAWvgnw4mg83zcaOuLTB0IRFfs5+ocaMuQXZzX5UGUh9blHxnuNAxydv/JhvYvlWOOTSKBC36/JtIp8wwtAatBCU9ieCslvT0JOxDGTEbqm0h4n7UWK5Vyv6AzRFjCGCXsiwa5IXB51oDo0GY0H9+VuMrFtFcXmw/6anM= 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.50 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-f50.google.com with SMTP id ffacd0b85a97d-462ebd5d37dso3434496f8f.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=l7+cpGnlZ7s7mPJAV7rarHLDR7QSMirCV1PN83eykkFmYfad3zdoymqlu29DS32fi7 9WNc3LRInDzmFZ24/4/eAUQri0MQJPcYbYVmIwBG9f7ji1kAIUkF2zfca5rRt0qNbhPl ObOuyNfWn0/nutJ8rrp8HbLKaWcnUCE7XBeR5tfiyo9fQC8c92rOk0VMDAUCk0Xzb2q+ 8iaT3+ugCO98Kllxrq03EzvTw85WeU4YOq7g1ypWXyD9oysH7NeTJov2JH3QOBF8zDaQ gs7BuHy/kZjkhFN8RnrM4uRND+8FiSwC/ZLyz79KU7QaO3z56YIP8GXB/kwxcSLAJ3Ok zxbA== X-Gm-Message-State: AOJu0YyzjStcA1V4vIoOwjnO1rPc+YTX23htm5POulqsDHcEAlP9yZ7G dio7oScrHH3Wm+8lMwygKrbM2wae5P8RjuAk7TvdZ9m2JRWml0tmXZiA X-Gm-Gg: AfdE7clS2JL585d96/oiH2dwui1M0Ap5XhyaPouocxuVNmNgh5OCJPkD1fgmLzMgrtN FYVTsVYeYCr5zYkU0jLPnj5EgpX6dcWh675eQefJBMQiVlEuZnaF6RVM6eVIr7QVNkXN6UIOPqb 5UzMdrbJz5OxcMhCh7CcpeZXMoOeRMWUFLJFdLhRXBL2pFBAeloeoRGxrcrSUlHJzNgVrw2yVNN KChYHLPwTqSPTHuC58Kgfh0X/eU8c2DJDNhnvfiZGjg+R+aMzl9b4OuIz5rtvXL5QBwaP0Ywm6H +YaPuvH/BG4N6J2O+SJu0gsfc8YAKCtmbVcg8PA/hUHKNPN6+Qna11NrmUQ8Eji2w5EjPfHQHgb CugKU5hg5XzpQ5XYh1XkyCL1stQrKymBQfJ3//jp1ck+oLe1pQtsD4tZYXjAo5w/at8UuMBfHUb F1hlRx9JZnY5TUH49RHF71Zj+NeR4K/FJ4wSEkCx7IuWOt6T/ZLwMLX1DyF+pp08lLs76EDeRA5 o6Ryt74NWM= 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-wireless@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