linux-kernel - Re: [PATCH] jffs2: remove fd from the f->dents list immediately.

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Mar 2018 12:52:47 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Joakim Tjernlund <Joakim.Tjernlund@...inera.com>,
        "yuyufen@...wei.com" <yuyufen@...wei.com>
Cc:     "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH] jffs2: remove fd from the f->dents list immediately.

On Fri, 2018-03-16 at 12:39 +0000, Joakim Tjernlund wrote:
> 
> > After reverting the commit, we test 'rm -r', which can remove all
> > files, and all seems OK!
> 
> UHH, this is mine (and Davids work from 2007)!
> I cannot remember  any details this long afterwards but I guess you cannot just
> revert that part as it triggers some other bug, David?

Right, the issue was with f_pos in the directory.

The 'rm' we were testing with at the time would delete a bunch of
directory entries, then continue with its readdir() to work out what
else to delete. But when we were handling f_pos on directories merely
as the position on the list, and when we were *deleting* things from
that list as we went, some dirents ended up moving so that they were
*before* the position that 'rm' had got to with its readdir().

But... the list we're traversing is *already* ordered by CRC, and that
could be a much saner thing to use as f_pos. We just have to make sure
we cope with hash collisions. Shifting left by 4 bits and using the low
4 bits would allow us to cope with 16 names with the same hash... but
I'm not sure that's good enough.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)