From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [Bug 49151] New: NULL pointer dereference in pata_acpi Date: Sun, 21 Oct 2012 18:57:56 +0200 Message-ID: <20121021165756.GA20642@liondog.tnic> References: <20121020120047.GC17563@liondog.tnic> <50841CFC.2030802@talktalk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: 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 Content-Disposition: inline In-Reply-To: <50841CFC.2030802@talktalk.net> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: phillip.wood@dunelm.org.uk Cc: "Anton V. Boyarshinov" , bugzilla-daemon@bugzilla.kernel.org, linux-ide@vger.kernel.org, Jeff Garzik , Alan Cox 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; } -- 1.8.0.rc2 -- Regards/Gruss, Boris.