linux-kernel - Re: blk: NULL ptr deref in blk_dequeue

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: <alpine.LNX.2.00.1210082340501.19980@pobox.suse.cz>
Date:	Mon, 8 Oct 2012 23:45:33 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Jan Kara <jack@...e.cz>
Cc:	Sasha Levin <levinsasha928@...il.com>, Tejun Heo <tj@...nel.org>,
	axboe@...nel.dk, Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: blk: NULL ptr deref in blk_dequeue_request()

On Mon, 8 Oct 2012, Jan Kara wrote:

> > I'm still seeing this on linux-next.
>   I think this is floppy related (see redo_fd_request() in the stack
> trace). And there were quite some changes to the area recently. Adding
> maintainer to CC.

Hmm ... I don't immediately see how this is happening.

Sasha, could you please do git bisect on drivers/block/floppy.c between 
f6365201d and your git HEAD for starters (assuming that f6365201d works 
well for you?).

> > On Sat, Sep 22, 2012 at 4:35 PM, Sasha Levin <levinsasha928@...il.com> wrote:
> > > Hi all,
> > >
> > > While fuzzing with trinity inside a KVM tools guest running the latest linux-next kernel, I've stumbled on the following BUG.
> > >
> > > I've also hit a similar trace where the 'BUG_ON(ELV_ON_HASH(rq));' above that list_del_init() gets hit, so I guess it's a race
> > > condition of some sorts.
> > >
> > >
> > > [    9.900299] BUG: unable to handle kernel NULL pointer dereference at           (null)
> > > [    9.909508] IP: [<ffffffff819ea637>] __list_del_entry+0xb7/0xe0
> > > [    9.910191] PGD 0
> > > [    9.910191] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > [    9.910191] Dumping ftrace buffer:
> > > [    9.910191]    (ftrace buffer empty)
> > > [    9.910191] CPU 2
> > > [    9.910191] Pid: 3996, comm: kworker/u:2 Tainted: G        W    3.6.0-rc6-next-20120921-sasha-00001-geb77a39-dirty #3
> > > [    9.910191] RIP: 0010:[<ffffffff819ea637>]  [<ffffffff819ea637>] __list_del_entry+0xb7/0xe0
> > > [    9.910191] RSP: 0000:ffff880034e11c88  EFLAGS: 00010007
> > > [    9.910191] RAX: 0000000000000000 RBX: ffff880034e3ec00 RCX: dead000000200200
> > > [    9.910191] RDX: 0000000000000000 RSI: ffffffff85366998 RDI: ffff880034e3ec00
> > > [    9.910191] RBP: ffff880034e11c88 R08: 0000000000000000 R09: ffff88001af60928
> > > [    9.910191] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> > > [    9.910191] R13: ffffffff85366360 R14: 0000000000000000 R15: ffffffff85b4edd0
> > > [    9.910191] FS:  0000000000000000(0000) GS:ffff880029800000(0000) knlGS:0000000000000000
> > > [    9.910191] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > [    9.910191] CR2: 0000000000000000 CR3: 0000000004c26000 CR4: 00000000000406e0
> > > [    9.910191] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > [    9.910191] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > [    9.910191] Process kworker/u:2 (pid: 3996, threadinfo ffff880034e10000, task ffff88001af60000)
> > > [    9.910191] Stack:
> > > [    9.910191]  ffff880034e11ca8 ffffffff819a1a45 ffff880034e3ec00 0000000000000000
> > > [    9.910191]  ffff880034e11cc8 ffffffff819a1ae1 0000000000000000 ffff880034e3ec00
> > > [    9.910191]  ffff880034e11ce8 ffffffff819a271e 0000000000000000 0000000000000000
> > > [    9.910191] Call Trace:

Seems like the queue obtained in set_next_request() through

	q = unit[fdc_queue].gendisk->queue;

is not a proper one. I am currently not sure why.

> > > [    9.910191]  [<ffffffff819a1a45>] blk_dequeue_request+0x35/0xc0
> > > [    9.910191]  [<ffffffff819a1ae1>] blk_start_request+0x11/0x40
> > > [    9.910191]  [<ffffffff819a271e>] blk_fetch_request+0x1e/0x30
> > > [    9.910191]  [<ffffffff81e5a89d>] redo_fd_request+0x9d/0x3f0
> > > [    9.910191]  [<ffffffff8112a779>] process_one_work+0x3b9/0x770
> > > [    9.910191]  [<ffffffff8112a628>] ? process_one_work+0x268/0x770
> > > [    9.910191]  [<ffffffff81177a22>] ? get_lock_stats+0x22/0x70
> > > [    9.910191]  [<ffffffff81e5a800>] ? start_motor+0x120/0x120
> > > [    9.910191]  [<ffffffff8112b0fa>] worker_thread+0x2ba/0x3f0
> > > [    9.910191]  [<ffffffff8112ae40>] ? rescuer_thread+0x2d0/0x2d0
> > > [    9.910191]  [<ffffffff81135d83>] kthread+0xe3/0xf0
> > > [    9.910191]  [<ffffffff81177aae>] ? put_lock_stats.isra.16+0xe/0x40
> > > [    9.910191]  [<ffffffff81135ca0>] ? insert_kthread_work+0x90/0x90
> > > [    9.910191]  [<ffffffff839f1e45>] kernel_thread_helper+0x5/0x10
> > > [    9.910191]  [<ffffffff81135ca0>] ? insert_kthread_work+0x90/0x90
> > > [    9.910191] Code: 6a 84 be 3e 00 00 00 48 c7 c7 7b d8 6a 84 31 c0 e8 8f c2 71 ff eb 2c 0f 1f 44 00 00 48 b9 00 02 20 00 00 00
> > > ad de 48 39 c8 74 8c <4c> 8b 00 4c 39 c7 75 a6 4c 8b 42 08 4c 39 c7 75 bc 48 89 42 08
> > > [    9.910191] RIP  [<ffffffff819ea637>] __list_del_entry+0xb7/0xe0
> > > [    9.910191]  RSP <ffff880034e11c88>
> > > [    9.910191] CR2: 0000000000000000
> > >
> > >
> > > Thanks,
> > > Sasha

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/