Hello folk, The btrfs file system, part of the linux kernel, is vulnerable to a trivial hash-DoS attack. More details can be found here: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ Enjoy! Pascal Junod -- http://crypto.junod.info @cryptopathe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ adding linux-btrfs ] On Thu, Dec 13, 2012 at 05:56:37AM -0700, Pascal Junod wrote:> Hello folk, > > The btrfs file system, part of the linux kernel, is vulnerable to a > trivial hash-DoS attack. More details can be found here: > > http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/Hi Pascal, Thanks for taking the time to write this up. As far as I can tell, the looping was actually fixed in an older kernel and I just misread our version string in your original email. I''ll track down the commit that fixed things and send it off to the stable series. SuSE and Fujitsu have done a number of error handling cleanups, it should be one of those. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote:> Thanks for taking the time to write this up. As far as I can tell, the > looping was actually fixed in an older kernel and I just misread our > version string in your original email.Yeah, the blogpost says 3.3.7. I did a quick test with 3.7 and was not able to reproduce it. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 13, 2012 at 02:34:30PM -0700, David Sterba wrote:> On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote: > > Thanks for taking the time to write this up. As far as I can tell, the > > looping was actually fixed in an older kernel and I just misread our > > version string in your original email. > > Yeah, the blogpost says 3.3.7. I did a quick test with 3.7 and was not > able to reproduce it.I tried with 3.3 and every step between 3.3 and 3.7. I''m not able to reproduce the problem, and I did run with Hack=True in the script (thanks for the flag btw, I really like that). So, that leaves us with a few possibilities: 1) mount -o seclabel 2) The small size of the device 3) loopback I ran with a 1GB FS here on 3.3 and wasn''t able to trigger things. But Pascal, could you please help narrow the problem down? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 13, 2012 at 03:07:27PM -0700, Chris Mason wrote:> On Thu, Dec 13, 2012 at 02:34:30PM -0700, David Sterba wrote: > > On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote: > > > Thanks for taking the time to write this up. As far as I can tell, the > > > looping was actually fixed in an older kernel and I just misread our > > > version string in your original email. > > > > Yeah, the blogpost says 3.3.7. I did a quick test with 3.7 and was not > > able to reproduce it. > > I tried with 3.3 and every step between 3.3 and 3.7. I''m not able to > reproduce the problem, and I did run with Hack=True in the script > (thanks for the flag btw, I really like that). > > So, that leaves us with a few possibilities: > > 1) mount -o seclabel > 2) The small size of the device > 3) loopback > > I ran with a 1GB FS here on 3.3 and wasn''t able to trigger things. But > Pascal, could you please help narrow the problem down?Ok, I think what was happening on Pascal''s machine is that we are returning -EOVERFLOW and sometimes aborting the transaction (which turns the FS readonly). I have that fixed here. Rename I''m reodering the rename code a little bit to also handle the case where there are collisions on rename. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 14.12.12 15:29, Chris Mason a écrit :> Ok, I think what was happening on Pascal''s machine is that we are > returning -EOVERFLOW and sometimes aborting the transaction (which turns > the FS readonly). > > I have that fixed here. Rename I''m reodering the rename code a little > bit to also handle the case where there are collisions on rename.Please tell me if I can help by explaining more about my setup. Pascal -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html