Deadlock in VFS on corrupted filesystem

Deadlock in VFS on corrupted filesystem

[Jan Kara]

  Hello Al!

  Sami found in his testing a rather easy way to deadlock a system with
corrupted filesystem: Just have a directory D and inside D a directory
entry pointing to D itself (e.g. corrupt '.' directory entry to have other
name). Then when you try to remove the corrupted directory entry system
will deadlock because we will try to lock D both as a parent and a child.

Generally, when the directory structure is corrupted so that cycles are
created, our locking protocol is prone to deadlocks. This is somewhat
unpleasant if you have a system where you allow mounting untrusted media.
So my question is: Do we care? And if yes, how to best fix this? My naive
idea would be that we could check in d_instantiate() whether we are
creating a directory dentry and if yes, check that inode is not already
attached to a directory hierarchy (i.e. effectively forbid directory
hardlinks). But this might be a bit tricky given dentry aliases. So what
are your thoughts?

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: Deadlock in VFS on corrupted filesystem

[Sami Liedes]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Thu, May 10, 2012 at 10:01:19AM +0200, Jan Kara wrote:
> Generally, when the directory structure is corrupted so that cycles are
> created, our locking protocol is prone to deadlocks. This is somewhat
> unpleasant if you have a system where you allow mounting untrusted media.
> So my question is: Do we care? And if yes, how to best fix this? My naive
> idea would be that we could check in d_instantiate() whether we are
> creating a directory dentry and if yes, check that inode is not already
> attached to a directory hierarchy (i.e. effectively forbid directory
> hardlinks). But this might be a bit tricky given dentry aliases. So what
> are your thoughts?

Besides being a potential security problem, two other possible
considerations come to my mind. Not saying that either of these need
necessarily be big concern, just my thoughts:

* I think it could be sensibly argued that a filesystem implementation
  where the flipping of a single bit in a filesystem image can cause a
  deadlock is not very robust, i.e. this could plausibly happen
  without any malice;

* From testing perspective, and especially fuzz testing perspective,
  the tolerated presence of such flaws makes finding other, unrelated
  problems harder.

	Sami

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]