On 01/07/2012 11:46 PM, Francois Marier wrote: > Hi, > > (I'm guessing this might be the right list, but feel free to let me know if > there's a better one.)
This is the right place. > > It looks like I've hosed one of my hard drives through some clueless use of > the dd command (as root of course) and I'd like to understand what I did > wrong. > > I was trying to erase /dev/sda entirely so I did this: > > dd if=/dev/zero of=/dev/sda bs=8192 count=122095323 > > (That last number being the size of the drive in bytes divided by 8192.) > > My question is: is it possible that it could have gone pass the end of > /dev/sda and continued writing onto /dev/sdb? Short answer: no, dd cannot corrupt /dev/sdb if you only passed /dev/sda as an argument. There was a recent CVE [1] raised against the kernel where it _did_ allow SG_IO ioctl commands to write beyond partition bounds of certain SCSI disks. But in that case, it would only allow access to /dev/sda1 to corrupt any other partitions on /dev/sda (such as /dev/sda2); it did _not_ allow cross-disk corruption (that is, access to /dev/sda does not in any way grant access to /dev/sdb). Furthermore, that CVE required the use of ioctl() commands; but user-space programs like dd that stick to normal read() and write() calls are not impacted. The kernel constrains write() calls to a block device to fall within the size of that device, and won't allow you to go beyond its bounds. [1] https://bugzilla.redhat.com/show_bug.cgi?id=752375 -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
