Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2342090ybz; Thu, 23 Apr 2020 16:22:22 -0700 (PDT) X-Google-Smtp-Source: APiQypLZK+iFr8QLVwZ9RGIZoDDTNqptwDPSTPLc+dWn/Tj/9kpqEDMrRT7+DqzyKktaea+TN0rd X-Received: by 2002:a50:a985:: with SMTP id n5mr4881825edc.338.1587684142095; Thu, 23 Apr 2020 16:22:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587684142; cv=none; d=google.com; s=arc-20160816; b=XxVBZpI3admknPKNE0SPudnUxuBwKYg8aMwruwB30EYfsYdois3b4OMj4iREsLUXQd I/E7Y8K6vmQNhJM3yyd6PlxGFp3qd/RpYjEkJv7V/R1gI0SEJ9Op6hnbSKBMlyvd7KnW jrSWcbYpIEw6wg/M1eqoteLILwTDu0k8XzNRld3EtHAZf/zqs7hY/ZTy0rWR3rtxJMlf Ex6kNIccENTgbk/l7qGxyz/I1BN/ePxXHabm4vN3CjbqBq3wte7MC0OaTdEh10q+/Ii1 lKamV1vBujXHAp6zUjjBY/2UIBPYs8DaSlBS7HiTfeNGDTmDQHKXRCIUOZLrZAkJ32+r kFqA== 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=Wp/a6UlE3t0GO5VytpmXbQxHE+RXZSwbY8YIdlj/gU4=; b=KhB8IPyBF+sLQ0rYkuwWiW2na5OG/TIz/fPBW2N/MkuwGwidO8eMuUvcIel0bCP6yZ 3Xaw3ZgWWVCU73yNHslv4QoRqviZkOh5A9sQNV340xS/hBVzmnA5GFdWfGk2GJDu7rwO l7258xY53NFds3ONnYO54Hm0wGd3OrCtbrdH3ptTNJaqMyFkHEsq/6f4of7fsS7z63hk vTo8w5FyvZoEJy7mai7q1YwpCatHF7PpkwTu2PMZIIwomkWAYIwqHTd4+8voQ0hwoMGe m/bqqEFx+u/yoOt54Dz9Lz16OJilAKzQ5IZbhJ+fziF8/TeF/s9AbCwhy4z6CDRruP7m uBTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w11si2011580ejz.146.2020.04.23.16.21.59; Thu, 23 Apr 2020 16:22:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729557AbgDWXS0 (ORCPT + 99 others); Thu, 23 Apr 2020 19:18:26 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49042 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728277AbgDWXGi (ORCPT ); Thu, 23 Apr 2020 19:06:38 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvP-0004fk-Qy; Fri, 24 Apr 2020 00:06:31 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvO-00E6ma-GR; Fri, 24 Apr 2020 00:06:30 +0100 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, Denis Kirjanov , "Alan Stern" , "Jiri Kosina" Date: Fri, 24 Apr 2020 00:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 094/245] HID: Fix slab-out-of-bounds read in hid_field_extract In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Alan Stern commit 8ec321e96e056de84022c032ffea253431a83c3c upstream. The syzbot fuzzer found a slab-out-of-bounds bug in the HID report handler. The bug was caused by a report descriptor which included a field with size 12 bits and count 4899, for a total size of 7349 bytes. The usbhid driver uses at most a single-page 4-KB buffer for reports. In the test there wasn't any problem about overflowing the buffer, since only one byte was received from the device. Rather, the bug occurred when the HID core tried to extract the data from the report fields, which caused it to try reading data beyond the end of the allocated buffer. This patch fixes the problem by rejecting any report whose total length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow for a possible report index). In theory a device could have a report longer than that, but if there was such a thing we wouldn't handle it correctly anyway. Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com Signed-off-by: Alan Stern Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings --- drivers/hid/hid-core.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -248,6 +248,12 @@ static int hid_add_field(struct hid_pars offset = report->size; report->size += parser->global.report_size * parser->global.report_count; + /* Total size check: Allow for possible report index byte */ + if (report->size > (HID_MAX_BUFFER_SIZE - 1) << 3) { + hid_err(parser->device, "report is too long\n"); + return -1; + } + if (!parser->local.usage_index) /* Ignore padding fields */ return 0;