From patchwork Sun Oct 21 16:57:56 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 193049 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3A46A2C008C for ; Mon, 22 Oct 2012 03:58:04 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753395Ab2JUQ6B (ORCPT ); Sun, 21 Oct 2012 12:58:01 -0400 Received: from mail.skyhub.de ([78.46.96.112]:57133 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752397Ab2JUQ6A (ORCPT ); Sun, 21 Oct 2012 12:58:00 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1350838678; bh=xiEXWUUJa8ckO5svHNaOboaqrpiGQviD1oAJBg4vJMQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=beAcCBWWNwuDuIojdURFM0sr2gNZINyLE4hi1l AJS9xh3A6WI+wr+WIi/XcnNSHWgnVDmDKTQQurlJwIWSNwwk5PBLmJCObdxDeWZVYIo y62ikeB4uWYtaptQkGfpc5MFfPnumjjQXwYx52bMEXTiHneUCS/ZmzXWh8WJlXNRRc= Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JtWkyM2DvS0v; Sun, 21 Oct 2012 18:57:57 +0200 (CEST) Received: from liondog.tnic (p54B7F1C7.dip.t-dialin.net [84.183.241.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 686911D9C14; Sun, 21 Oct 2012 18:57:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1350838677; bh=xiEXWUUJa8ckO5svHNaOboaqrpiGQviD1oAJBg4vJMQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=gKgWUTAoW+pCo2Izodmszfz0+hW4tfYS6JSYZ0 Wtb5HCXwOwdtJJBaJUpVArOED1IwU7MxO6c48zO0hSAweHnvN/NlL88itFsMwh0gtm7 3MSn7H9tZ2/cfj/2xRypZmj1gQRRGXZEhrflomqVXHsAuCQh0Cyfl/IJPI4wrebjyE= Received: by liondog.tnic (Postfix, from userid 1000) id 4E5384B8EAA; Sun, 21 Oct 2012 18:57:56 +0200 (CEST) Date: Sun, 21 Oct 2012 18:57:56 +0200 From: Borislav Petkov To: phillip.wood@dunelm.org.uk Cc: "Anton V. Boyarshinov" , bugzilla-daemon@bugzilla.kernel.org, linux-ide@vger.kernel.org, Jeff Garzik , Alan Cox Subject: Re: [Bug 49151] New: NULL pointer dereference in pata_acpi Message-ID: <20121021165756.GA20642@liondog.tnic> References: <20121020120047.GC17563@liondog.tnic> <50841CFC.2030802@talktalk.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50841CFC.2030802@talktalk.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Sun, Oct 21, 2012 at 05:04:12PM +0100, Phillip Wood wrote: > Thanks for responding to the bug report so quickly. I've applied your > patch and the kernel now finds my hard drive and the logs (pasted > below) have a couple of warnings generated by the patch. So if I've > understood correctly then your theory that ata_timing_find_mode() is > returning NULL is correct. Yes, it appears so. > Thanks for looking into this, just let me know if you want me to do > anything else. Right, so we know what exactly happens and I think we have the right people on CC who can make sense of why it happens. If I'd be to guess, this is most probably a BIOS bug (what else?! :-)) which the pata_acpi code is not ready to handle. Btw, Jeff, AFAICT, libata code should the very least catch this situation so that we know. Patch for this below. From a quick look there a couple of drivers which do not check ata_timing_find_mode()'s retval and I guess at least issuing a warning in such situations could be helpful with future issues. However, I don't know how chatty this warning could become and whether this is the right approach and not auditing all users is better. What you can do, Phillip, is check whether some other specific PATA driver supports your hardware and enable it instead of PATA_ACPI. What does lspci on the box say? Or rather 'lspci -v' for more details. You can also send dmesg from the box. Thanks. --- From: Borislav Petkov Date: Sun, 21 Oct 2012 18:49:08 +0200 Subject: [PATCH] libata: Warn when unable to find timing descriptor based on xfer_mode ata_timing_find_mode could return NULL which is not checked by all low-level ATA drivers using it and cause a NULL ptr deref. Warn at least so that possible issues can get fixed easily. Signed-off-by: Borislav Petkov --- drivers/ata/libata-core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 3cc7096cfda7..f46fbd3bd3fb 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -2942,6 +2942,10 @@ const struct ata_timing *ata_timing_find_mode(u8 xfer_mode) if (xfer_mode == t->mode) return t; + + WARN_ONCE(true, "%s: unable to find timing for xfer_mode 0x%x\n", + __func__, xfer_mode); + return NULL; }