linux-ext4 - [PATCH 0/2] Fix wrong name_len and file

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 30 Aug 2009 16:56:40 +0200
From:	Andreas Schlick <schlick@...abit.com>
To:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: [PATCH 0/2] Fix wrong name_len and file_type in intermediate htree nodes

Hello,

while testing the dirshrink patch, I found that sometimes intermediate htree 
nodes end up with their fake_dirent's name_len and file_type not being zero. 
e2fsck will then consider the htree to be corrupted as it doesn't recognise 
that these blocks contain dx_nodes. 

As far as I understand it, this happens sometimes when ext4_dx_add_entry() has 
to create a new index node and calls ext4_append(). In the end ext4_getblk() 
is called and it might get a buffer that has BH_Uptodate set, causing 
ext4_getblk() to not zero it out and leave the old content intact. 

I can reproduce this with plain linux-2.6.30.5. To produce this I use a nearly 
full filesystem and continuously create new files in one directory while 
removing other directories/files at the same time. 

Do I understand it correctly, that it happens when the newly allocated block 
(for the new index node) was very recently used by another file/directory, so 
that it is still in the buffer cache? But it surprises me that it doesn't 
happen more often.

Andreas Schlick

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html