lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 1 Aug 2015 12:19:13 +0200 From: Dominique Martinet <asmadeus@...ewreck.org> To: Al Viro <viro@...IV.linux.org.uk> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Hugh Dickins <hughd@...gle.com>, "J. Bruce Fields" <bfields@...ldses.org>, Dominique Martinet <dominique.martinet@....fr>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, David Howells <dhowells@...hat.com> Subject: Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Al Viro wrote on Sat, Aug 01, 2015: > And that has turned the check done to an inode that *was* ours at some > point (i.e. fetching it had been followed by checking that ->d_seq had > been still valid) into something completely unprotected. Suppose we > are in lazy mode and somebody had evicted nd->path.dentry after we'd looked > it up and before that check. Sure, its ->d_seq had been bumped by that, > and we would've failed anyway. With ECHILD. Which, unlike ENOTDIR, is > "repeat in non-lazy mode". That sounds like a good find, I was looking at how to claim/protect the entry somehow as well but I just have no idea... > Folks, could you check if this fixes the problems you are seeing? > > diff --git a/fs/namei.c b/fs/namei.c > index ae4e4c1..b16c3a7 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -1954,7 +1954,11 @@ OK: > continue; > } > } > - if (unlikely(!d_can_lookup(nd->path.dentry))) > + if (unlikely(!d_can_lookup(nd->path.dentry))) { > + if (nd->flags & LOOKUP_RCU) { > + if (unlazy_walk(nd, NULL, 0)) > + return -ECHILD; > + } > return -ENOTDIR; > } > } Unfortunately, still happens for me. I had to adapt a bit because using an old kernel (4bf46a272), will try again with a recent master to doublecheck, but I had a break on the "if (nd->flags & LOOKUP_RCU)" check: - sometimes fails without ever hitting the check. I think this fixes the "ENOTDIR" I had described, but there's at least another way to fail? - When we do hit it, we're into LOOKUP_RCU at this point alright, unlazy_walk fails and we try again without RCU -- can confirm the recovery process goes OK (well, that it went OK at least once) Thanks, -- Dominique -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists