similar to: [PATCH] virtio-blk: Allow extended partitions

This will allow up to DISK_MAX_PARTS (256) partitions, with for example GPT in the guest. Otherwise, the partition scan code will only discover the first 15 partitions. Signed-off-by: Fam Zheng <famz at redhat.com> --- drivers/block/virtio_blk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index d4d05f0..38ea01b 100644 ---

This will allow up to DISK_MAX_PARTS (256) partitions, with for example GPT in the guest. Otherwise, the partition scan code will only discover the first 15 partitions. Signed-off-by: Fam Zheng <famz at redhat.com> --- drivers/block/virtio_blk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index d4d05f0..38ea01b 100644 ---

Current index allocation in virtio-blk is based on a monotonically increasing variable "index". It could cause some confusion about disk name in the case of hot-plugging disks. And it's impossible to find the lowest available index by just maintaining a simple index. So it's changed to use ida to allocate index via referring to the index allocation in scsi disk. Signed-off-by:

Current index allocation in virtio-blk is based on a monotonically increasing variable "index". It could cause some confusion about disk name in the case of hot-plugging disks. And it's impossible to find the lowest available index by just maintaining a simple index. So it's changed to use ida to allocate index via referring to the index allocation in scsi disk. Signed-off-by:

Based on a patch by Mark Wu <dwu at redhat.com> Current index allocation in virtio-blk is based on a monotonically increasing variable "index". This means we'll run out of numbers after a while. It also could cause confusion about the disk name in the case of hot-plugging disks. Change virtio-blk to use ida to allocate index, instead. Signed-off-by: Michael S. Tsirkin

Based on a patch by Mark Wu <dwu at redhat.com> Current index allocation in virtio-blk is based on a monotonically increasing variable "index". This means we'll run out of numbers after a while. It also could cause confusion about the disk name in the case of hot-plugging disks. Change virtio-blk to use ida to allocate index, instead. Signed-off-by: Michael S. Tsirkin

From: Stefan Hajnoczi <stefanha at redhat.com> [ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ] A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer

On Tue, Apr 28, 2020 at 03:30:09PM +0100, Stefan Hajnoczi wrote: > A userspace process holding a file descriptor to a virtio_blk device can > still invoke block_device_operations after hot unplug. For example, a > program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot > unplug to invoke virtblk_getgeo(). which causes what? a use after free? > > Introduce a

On Wed, Apr 29, 2020 at 05:53:45PM +0100, Stefan Hajnoczi wrote: > A userspace process holding a file descriptor to a virtio_blk device can > still invoke block_device_operations after hot unplug. This leads to a > use-after-free accessing vblk->vdev in virtblk_getgeo() when > ioctl(HDIO_GETGEO) is invoked: > > BUG: unable to handle kernel NULL pointer dereference at

Previously after device_add_disk returns, the KOBJ_ADD uevent is already emitted. Adding attributes after that is a poor usage of kobject, and in practice may result in race conditions with userspace, for example udev checks availability of certain attributes and initializes /dev entries conditionally. device_add_disk can handle adding attribute group better, so use it. Meanwhile, handle error

From: Stefan Hajnoczi <stefanha at redhat.com> [ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ] A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer

From: Stefan Hajnoczi <stefanha at redhat.com> [ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ] A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer

From: Stefan Hajnoczi <stefanha at redhat.com> [ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ] A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer

On Tue, Apr 28, 2020 at 11:25:07AM -0400, Michael S. Tsirkin wrote: > On Tue, Apr 28, 2020 at 03:30:09PM +0100, Stefan Hajnoczi wrote: > > A userspace process holding a file descriptor to a virtio_blk device can > > still invoke block_device_operations after hot unplug. For example, a > > program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot > > unplug to

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. For example, a program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot unplug to invoke virtblk_getgeo(). Introduce a reference count in struct virtio_blk so that its lifetime covers both virtio_driver probe/remove and block_device_operations open/release

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. For example, a program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot unplug to invoke virtblk_getgeo(). Introduce a reference count in struct virtio_blk so that its lifetime covers both virtio_driver probe/remove and block_device_operations open/release

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called