linux-ext4 - Re: Data races in ext4

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-prev] [day] [month] [year] [list]

Date:	Fri, 11 Apr 2014 15:08:00 +0200
From:	Pedro Fonseca <pfonseca@...-sws.org>
To:	Theodore Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org, adilger.kernel@...ger.ca
Subject: Re: Data races in ext4


>> Regarding the generic_fillattr() function, apart from the inconsistency
>> between i_blocks/i_size, it looks like it can also cause wrong values to be
>> returned because several of those fields are 64 bits.
> Well, it's actually a 32-bit seconds and 32-bit nanoseconds field.  So
> we could theoretically get a torn value, but if the ns field is from a
> previous update, the worst that could happen under those circumstances
> is that two quick successive stat() commands could potentially result
> in end up with an apparent "time moving backwards" in the nanoseconds
> field.  If someone was constantly calling utimes(2) to modify the
> mtime/atime at high rate, that might cause a more serious wrong value,
> but that's an argument you should take up with the generic VFS folks
> as to whether it's important enough that they would want to care about
> it.

Note that the races in stat() also involve the "inode->i_blocks" field, 
which is also 64-bits. So, as far as I understand, this field too can 
get wrapped, although it should only affect very large files. (On the 
other hand, the field inode->i_size seems to be protected.)

I'll follow your suggestion and let the VFS developers know about this.


> P.S.  What did you use to generate these reports?  Is it something
> that can be easily replicated by others?

We're currently developing an experimental tool to test the kernel for 
concurrency bugs. It's not yet publicly available, but we hope it will 
become available at some point in the future.

Thanks,
Pedro
--
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