Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2334870ybz; Thu, 23 Apr 2020 16:14:14 -0700 (PDT) X-Google-Smtp-Source: APiQypKq+l5g5tHRjhGspQ48OFQ1vER+fygChfCRao/l64zVUW7ZMFLKAV/Vo1j5RjH9QCZho0PF X-Received: by 2002:a17:906:6845:: with SMTP id a5mr4495455ejs.143.1587683654342; Thu, 23 Apr 2020 16:14:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683654; cv=none; d=google.com; s=arc-20160816; b=IR4zFWXYDMXulpCtawuzFMjHoKWUgjsvRKT2gRwA/baNA/uGbTuhK1m0w7yEoF7Ddt 6DuyR6k+u/TnC2PDqyPxXVeLhT1TomzjVVqcCRZ4EaL5ZAdori0p14VbKJQZHeHN+6l1 0jkt1P5/mDr0WKif9f4yh28ekiWVelgSFv+QZBHV+Tm+/KEfBh4ImWmrCBV1DQKOt8ps DPYBrxbIvueOvJIGyH+lA0P83xNKDsj+WHmAPxiyWPE8gM4Q/ISmP06PEDH76Bi2rtJH tsOOPPTlYpO0WAdO5IOTUnwBXcr+8iKKCEAnyEaEp3WN3uFn6tkzX7/kHQIvtNALxQbq rxHA== 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=iLRWrh2662XcsJ+Aou7+wHWfmU6uhggEngN6gN616N8=; b=YGugpwrDq8gQMheIC5lQ8roCg063ZQFdw2Ly5ODvE4B6MgnKX51HN5qozI7pXL9j8y Xbm5sHaoP2v+RBYlVm5oeqyuhvKz/ZKzxsvL4dNq9u9xGp6oocbXUd0xiLlbBLG28fZN dAD5g2TAVWL9bVmWVcIwELuJL8JXj5SXzdwbdmG+fOJga+RtpG0Sc3jN3WLW6YIxrvy4 uk7q6xzF4/0iJrrg3Yx6PjrCTj8qLcBzmLyd7u7hbaAyi8Rn9W5jDwh+QdAVtKiAzSu8 clVsieMhMBZOWSovXhP7Y0GD62PkMXyBe7TTYVf3kzeEFzm4/Xpmf4UfhtRGtHltW+rR pCvw== 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 me3si2089213ejb.250.2020.04.23.16.13.50; Thu, 23 Apr 2020 16:14:14 -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 S1728687AbgDWXJ0 (ORCPT + 99 others); Thu, 23 Apr 2020 19:09:26 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50852 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728646AbgDWXG6 (ORCPT ); Thu, 23 Apr 2020 19:06:58 -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 1jRkvk-0004xG-6j; Fri, 24 Apr 2020 00:06:52 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvf-00E72K-Eh; Fri, 24 Apr 2020 00:06:47 +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 , "Dan Carpenter" , "Willy Tarreau" , "Linus Torvalds" , "Jordy Zomer" Date: Fri, 24 Apr 2020 00:07:31 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 224/245] floppy: check FDC index for errors before assigning it 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: Linus Torvalds commit 2e90ca68b0d2f5548804f22f0dd61145516171e3 upstream. Jordy Zomer reported a KASAN out-of-bounds read in the floppy driver in wait_til_ready(). Which on the face of it can't happen, since as Willy Tarreau points out, the function does no particular memory access. Except through the FDCS macro, which just indexes a static allocation through teh current fdc, which is always checked against N_FDC. Except the checking happens after we've already assigned the value. The floppy driver is a disgrace (a lot of it going back to my original horrd "design"), and has no real maintainer. Nobody has the hardware, and nobody really cares. But it still gets used in virtual environment because it's one of those things that everybody supports. The whole thing should be re-written, or at least parts of it should be seriously cleaned up. The 'current fdc' index, which is used by the FDCS macro, and which is often shadowed by a local 'fdc' variable, is a prime example of how not to write code. But because nobody has the hardware or the motivation, let's just fix up the immediate problem with a nasty band-aid: test the fdc index before actually assigning it to the static 'fdc' variable. Reported-by: Jordy Zomer Cc: Willy Tarreau Cc: Dan Carpenter Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- drivers/block/floppy.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -847,14 +847,17 @@ static void reset_fdc_info(int mode) /* selects the fdc and drive, and enables the fdc's input/dma. */ static void set_fdc(int drive) { + unsigned int new_fdc = fdc; + if (drive >= 0 && drive < N_DRIVE) { - fdc = FDC(drive); + new_fdc = FDC(drive); current_drive = drive; } - if (fdc != 1 && fdc != 0) { + if (new_fdc >= N_FDC) { pr_info("bad fdc value\n"); return; } + fdc = new_fdc; set_dor(fdc, ~0, 8); #if N_FDC > 1 set_dor(1 - fdc, ~8, 0);