linux-ext4 - Bug: {m,a}time issue 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>] [day] [month] [year] [list]

Message-ID: <0cde87b04ffccea1719810a6a93f353d@leptonyx.com>
Date:	Wed, 17 Feb 2016 21:58:05 +0000
From:	Pete <pete@...tonyx.com>
To:	linux-ext4@...r.kernel.org
Subject: Bug: {m,a}time issue in ext4

I don't know if this is the right place to report this - please correct 
me if it isn't the case.

The touch command on Linux currently allows a user to set a file's 
{m,a}time field in an ext4 filesystem to datetimes outside the bounds 
allowed by the filesystem (1901-12-13 20:45:52 to 2446-05-10 23:38:55) 
with impunity, flagging no error or warning.

This results in the storing of the relevant modulo bits in i_{m,a}time 
and i_{m,a}time_extra, but retaining the erroneous original value at 
some place in the filesystem cache.

Thus, subsequent calls to stat or ls -l will display the erroneous 
value, and will carry on doing so until the filesystem is remounted, in 
which case the timestamp bits are then re-read from scratch and 
interpreted correctly by stat and ls -l.

This means, among other aspects, that someone can set an out-of-bounds 
value, unmount and remount the filesystem, and find the datetime to have 
changed from the one which they believed to have entered, and which was 
reported previously.

Behaviour observed in (kernel 4.4.0-3 / e2fsprogs-1.42.13-3.3.x86_64) 
and (kernel 3.19.0 / e2fsprogs 1.42.9).

--
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