linux-kernel - Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171107140102.n2pncsaer5o5hmt7@pd.tnic>
Date:   Tue, 7 Nov 2017 15:01:02 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Fengguang Wu <fengguang.wu@...el.com>
Cc:     linux-ide@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jens Axboe <axboe@...nel.dk>,
        Bart Van Assche <bart.vanassche@...disk.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer
 dereference at 000001c0

On Tue, Nov 07, 2017 at 09:06:26PM +0800, Fengguang Wu wrote:
> It turns out rather hard to reproduce -- that's the only occurrence in
> 100 boots. Perhaps we'll have to give up on this.

Right,

you could blacklist CONFIG_IDE from your randconfig testing - IDE has
been going away since forever :-)

Alternatively, we could brown-paper bag it with something like this:

---
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index a7355ab3bb22..6ff0be8cbdc9 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -867,11 +867,16 @@ static void msf_from_bcd(struct atapi_msf *msf)
 int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
 {
 	struct cdrom_info *info = drive->driver_data;
-	struct cdrom_device_info *cdi = &info->devinfo;
+	struct cdrom_device_info *cdi;
 	unsigned char cmd[BLK_MAX_CDB];
 
 	ide_debug_log(IDE_DBG_FUNC, "enter");
 
+	if (!info)
+		return -EIO;
+
+	cdi = &info->devinfo;
+
 	memset(cmd, 0, BLK_MAX_CDB);
 	cmd[0] = GPCMD_TEST_UNIT_READY;
--

but from looking at this (I had forgotten how, hm, "interesting" the
IDE code was :-)) it looks like some sort of a race where we've called
->release earlier and drive->driver_data is gone by the time the
workqueue function runs. Or something to that effect...

Anyway, you can still give me your qemu command line and I can try to
debug it, if you'd like. But yeah, it would probably be a waste of time
as IDE is long deprecated...

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.