Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2990567imu; Sun, 9 Dec 2018 14:28:12 -0800 (PST) X-Google-Smtp-Source: AFSGD/XJ3Go29NuhJmcmUoNI5HuxeP/Iq0f13xIjDe+bC8ux4wTmyUjkmmPeA7CZkrKT4o0zrWJR X-Received: by 2002:a65:6684:: with SMTP id b4mr8916843pgw.55.1544394492246; Sun, 09 Dec 2018 14:28:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544394492; cv=none; d=google.com; s=arc-20160816; b=ffutXKDzXBDBytjtsJkNE40qqhbj9F+MoMAweDxEyi3tz0eoYmcoEc6F7pV4VT4bkV 7/HvTmv2TmTgQ+isQ2JECrN30s3TgeOrVgWmpEbhMzouAeK42vUGHl8TeVTN5G4LGqDh CD7BBvtqKt5sjli0nnHwaWyflJteAsITupcS3MA+D60+trz3DKhZz3cZrl3Q7U00z1xz Ywb/o8g9PFljcc32x+3VimEB5ox9lEZs+zapRa2+T/e5cWLT4Hod396BVajfb1xBZnDa SeWGLjnsmXbVbMrXDepxwd6nytlL0z89p9LwfrNY+RY5i/VWy5wjkx9KLHRE6WI8wZae rf4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=lepDAL047fvlPBWXDt6CL5TFApJq26iMouiPVq4PzF4=; b=OYsv83ubii5RmqZ+Trz8eteRYaV8/2NxmKQnNcpjink0dnKDJxNQ0YKsrGNx/Ad9cN kxJmPYcTAqKAd2HmRoCjgFjul/HwKmlBdgNvHkCzmag6kaglI78mfU0ISrmWxyoMjiTx SZqVROtg0nYIhfnKSaSBUHXQGalpf1KHn4YMwKwbyUTC1OWxfROohcAtt8nlOVkLaowh csKE1gLzLJVB9DEp1jcgqdCjXH4loOEzNZsY0n3KW4F2M7QAOUOnErmc8CxbR185AO/M EQH8GUpTqKSBD6IwR4JQcxttsn1AuqlZj6xlv1A7SPCDyzTgj/0trAVkIJ/xKtHQgzU3 X+Ug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g59si8744100plb.302.2018.12.09.14.27.48; Sun, 09 Dec 2018 14:28:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728782AbeLIW03 (ORCPT + 99 others); Sun, 9 Dec 2018 17:26:29 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34786 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726309AbeLIVzO (ORCPT ); Sun, 9 Dec 2018 16:55:14 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72d-0002ii-IU; Sun, 09 Dec 2018 21:55:12 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72Y-0003Cs-1h; Sun, 09 Dec 2018 21:55:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Dan Carpenter" , "Kalle Valo" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 010/328] rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication() In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Dan Carpenter commit ae636fb1554833ee5133ca47bf4b2791b6739c52 upstream. This is a static checker fix, not something I have tested. The issue is that on the second iteration through the loop, we jump forward by le32_to_cpu(auth_req->length) bytes. The problem is that if the length is more than "buflen" then we end up with a negative "buflen". A negative buflen is type promoted to a high positive value and the loop continues but it's accessing beyond the end of the buffer. I believe the "auth_req->length" comes from the firmware and if the firmware is malicious or buggy, you're already toasted so the impact of this bug is probably not very severe. Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings --- drivers/net/wireless/rndis_wlan.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/wireless/rndis_wlan.c +++ b/drivers/net/wireless/rndis_wlan.c @@ -2917,6 +2917,8 @@ static void rndis_wlan_auth_indication(s while (buflen >= sizeof(*auth_req)) { auth_req = (void *)buf; + if (buflen < le32_to_cpu(auth_req->length)) + return; type = "unknown"; flags = le32_to_cpu(auth_req->flags); pairwise_error = false;