[dm-devel] device mapper and the BLKFLSBUF ioctl
Mikulas Patocka
mpatocka at redhat.com
Fri Oct 21 20:18:37 UTC 2016
On Fri, 21 Oct 2016, Mike Snitzer wrote:
> On Fri, Oct 21 2016 at 2:33pm -0400,
> Mikulas Patocka <mpatocka at redhat.com> wrote:
>
> > Hi
> >
> > I found a bug in dm regarding the BLKFLSBUF ioctl.
> >
> > The BLKFLSBUF ioctl can be called on a block device and it flushes the
> > buffer cache. There is one exception - when it is called on ramdisk, it
> > actually destroys all ramdisk data (it works like a discard on the full
> > device).
> >
> > The device mapper passes this ioctl down to the underlying device, so when
> > the ioctl is called on a logical volume, it can be used to destroy the
> > underlying volume group if the volume group is on ramdisk.
> >
> > For example:
> > # modprobe brd rd_size=1048576
> > # pvcreate /dev/ram0
> > # vgcreate ram_vg /dev/ram0
> > # lvcreate -L 16M -n ram_lv ram_vg
> > # blockdev --flushbufs /dev/ram_vg/ram_lv
> > --- and now the whole volume group is gone, all data on the
> > ramdisk were replaced with zeroes
> >
> > The BLKFLSBUF ioctl is only allowed with CAP_SYS_ADMIN, so there shouldn't
> > be security implications with this.
> >
> > Whan to do with it? The best thing would be to drop this special ramdisk
> > behavior and make the BLKFLSBUF ioctl flush the buffer cache on ramdisk
> > like on all other block devices. But there may be many users having
> > scripts that depend on this special behavior.
> >
> > Another possibility is to stop the device mapper from passing the
> > BLKFLSBUF ioctl down.
>
> If anything DM is being consistent with what the underlying device is
> meant to do.
>
> brd_ioctl() destroys the data in response to BLKFLSBUF.. I'm missing why
> this is a DM-specific problem.
The problem is that if we call it on a logical volume, it destroys all
logical volumes on the give physical volume.
Mikulas
More information about the dm-devel
mailing list