----- Original Message ----- > From: "Anand Jain" <anand.jain@xxxxxxxxxx> > To: "Timothy Pearson" <tpearson@xxxxxxxxxxxxxxxxxxxxx>, "linux-btrfs" <linux-btrfs@xxxxxxxxxxxxxxx> > Sent: Tuesday, November 12, 2019 9:41:21 PM > Subject: Re: Potential CVE due to malicious UUID conflict? > On 13/11/19 9:37 AM, Timothy Pearson wrote: >> I was recently informed on #btrfs that simply attaching a device with the same >> UUID as an active BTRFS filesystem to a system would cause silent corruption of >> the active disk. >> > >> Two questions, since this seems like a fairly serious and potentially CVE-worthy >> bug (trivial case would seem to be a USB thumbdrive with a purposeful UUID >> collision used to quietly corrupt data on a system that is otherwise secured): >> >> 1.) Is this information correct? >> 2.) Does https://lkml.org/lkml/2019/2/10/23 offer sufficient protection against >> a malicious device being attached iff the malicious device is never mounted? >> >> Thank you! >> > > Corruption of the data is not possible at all. Because when the device > is mounted its already been excl-opened for RW and we won't > close/replace it unless unmounted. And while the device is mounted > if there is malicious device with the same UUID, then any scan shall > fail with -EEXIST if the kernel has the commit as in [2] (above). > > However if the kernel does not have [2], then it will just > appear as if the original device path has been replaced, but > underneath the RW IOs are still going to the original device > and not to the malicious device, so its safe. > > > HTH > > Thanks, > Anand Thank you, that helps greatly! I was very concerned when I heard that info on IRC, and wanted to verify here. Aside from the "interesting" corruption bug we hit on 5.3-rc3, BTRFS has been overall very stable and reliable for us. I'm glad we don't have to worry about this type of attack (or admin oops, for that matter).
