linux-kernel - Re: [PATCH] block: fix del_gendisk() vs blkdev

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] [day] [month] [year] [list]

Message-ID: <CAPcyv4hg8Tqs0h__-4hc8qVkekRok+osiXawHGnr==0ZQtAXsQ@mail.gmail.com>
Date:	Thu, 17 Dec 2015 14:38:10 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Jens Axboe <axboe@...com>
Cc:	linux-block@...r.kernel.org, Robert Hu <robert.hu@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
Subject: Re: [PATCH] block: fix del_gendisk() vs blkdev_ioctl crash

On Thu, Dec 17, 2015 at 2:26 PM, Dan Williams <dan.j.williams@...el.com> wrote:
> When tearing down a block device early in its lifetime, userspace may
> still be performing discovery actions like blkdev_ioctl() to re-read
> partitions.
>
> The nvdimm_revalidate_disk() implementation depends on
> disk->driverfs_dev to be valid at entry.  However, it is set to NULL in
> del_gendisk() and fatally this is happening *before* the disk device is
> deleted from userspace view.
>
> There's no reason for del_gendisk() to clear ->driverfs_dev.  That
> device is the parent of the disk.  It is guaranteed to not be freed
> until the disk, as a child, drops its ->parent reference.
>
> We could also fix this issue locally in nvdimm_revalidate_disk() by
> using disk_to_dev(disk)->parent, but lets fix it globally since
> ->driverfs_dev follows the lifetime of the parent.  Longer term we
> should probably just add a @parent parameter to add_disk(), and stop
> carrying this pointer in the gendisk.
>
>  BUG: unable to handle kernel NULL pointer dereference at           (null)
>  IP: [<ffffffffa00340a8>] nvdimm_revalidate_disk+0x18/0x90 [libnvdimm]
>  CPU: 2 PID: 538 Comm: systemd-udevd Tainted: G           O    4.4.0-rc5 #2257
>  [..]
>  Call Trace:
>   [<ffffffff8143e5c7>] rescan_partitions+0x87/0x2c0
>   [<ffffffff810f37f9>] ? __lock_is_held+0x49/0x70
>   [<ffffffff81438c62>] __blkdev_reread_part+0x72/0xb0
>   [<ffffffff81438cc5>] blkdev_reread_part+0x25/0x40
>   [<ffffffff8143982d>] blkdev_ioctl+0x4fd/0x9c0
>   [<ffffffff811246c9>] ? current_kernel_time64+0x69/0xd0
>   [<ffffffff812916dd>] block_ioctl+0x3d/0x50
>   [<ffffffff81264c38>] do_vfs_ioctl+0x308/0x560
>   [<ffffffff8115dbd1>] ? __audit_syscall_entry+0xb1/0x100
>   [<ffffffff810031d6>] ? do_audit_syscall_entry+0x66/0x70
>   [<ffffffff81264f09>] SyS_ioctl+0x79/0x90
>   [<ffffffff81902672>] entry_SYSCALL_64_fastpath+0x12/0x76
>
> Reported-by: Robert Hu <robert.hu@...el.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>

I forgot to add:

Cc: <stable@...r.kernel.org>
--
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/