Deadlock with overlayfs over and IMA/EVM-enabled filesystem
Hi Krisztian,
(Reposting my response as it never made it to the mailing list.)
Quoted 12 lines
Hi,
I've run into a reliably reproducible deadlock/reversed locking order bug involving overlayfs and IMA-enabled filesystems. It can be triggered very simply by constructing a read-write overlay using lower, upper, and work directories all on IMA-enabled filesystems. With such a setup simply trying to create an empty file by touch triggers the bug. Retrying the same thing with the upper and work directories on an IMA-ignored filesystem (for instance on a tmpfs) avoids the problem. From the stack trace it looks like we get into the deadlock when IMA tries to update the extended attribute for the newly created file which calls thru vfs into overlayfs.
Right, ima_file_free(), which is called from __fput(), writes the file hash as a security xattr. This seems to trigger the overlay's writing of the xattr. Testing if the S_IMA flag is set before taking the i_mutex would probably prevent the lockdep.
Quoted 3 lines
The setup is arguably a corner case (I don't think there are hoards of folks trying to mix overlays with IMA), but I'm not sure if the same problem could be triggered by something less pathological.
Deferring __fput() was introduced back in 2012 in order for IMA to take the i_mutex. So it shouldn't be a problem.
Mimi