linux-ext4 - Re: [BUG] ext4 timestamps corruption

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

Message-Id: <3BB3CFE7-BD50-4123-A1C8-D3FDAAD184DA@gmail.com>
Date:	Sat, 11 Jun 2011 10:48:44 -0600
From:	Andreas Dilger <aedilger@...il.com>
To:	Akira Fujita <a-fujita@...jp.nec.com>
Cc:	"Theodore Tso , ext4 development" <tytso@....edu>
Subject: Re: [BUG] ext4 timestamps corruption

On 2011-06-10, at 2:27 AM, Akira Fujita <a-fujita@...jp.nec.com> wrote:
> 
> Officially, ext4 can handle its timestamps until 2514
> with 32bit entries plus EPOCH_BIT (2bits).
> But when timestamps values use 32+ bit
> (e.g. 2038-01-19 9:14:08 0x0000000080000000),
> we can get corrupted values.
> Because sign bit is overwritten by transferring value
> between kernel space and user space.
> 
> This can be happened with kernel 3.0.0-rc2 (Also older kernel)
> on x86_64.
> 
> # This issue is already on Bugzilla,
>  does anybody know this current status?
> https://bugzilla.kernel.org/show_bug.cgi?id=23732

I can't find any discussion about this bug in the list archives, but it is definitely a real problem.

At first glance, it appears that the correct solution is to shift the high
bits in the extra time by only 31 bits.

As stated in the posting, it makes sense to keep the range -2^31 - +2^33
for maximum usability. I don't think there is any value to store more
negative times.

To be honest I also don't think there is any value to even keeping negative
timestamps (before 1970) since this is about storing file creation or
modification times and I don't think any files with real creation dates
before 1970 are used anywhere.

Either way I expect the time range to be sufficient, once the bug is fixed.

> Reproduce steps are as follows:
> # System time is set to UTC.
> 
> # mount -t ext4 /dev/sda8 /mnt/mp1
> 
> # touch -t 203801190314.08 /mnt/mp1/FILE
> 
> # umount /mnt/mp1
> # mount -t ext4 /dev/sda8 /mnt/mp1
> 
> # stat /mnt/mp1/FILE
>  File: `/mnt/mp1/FILE'
>  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
> Device: 808h/2056d    Inode: 12          Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 1901-12-13 20:45:52.000000000 +0000       <-----
> Modify: 1901-12-13 20:45:52.000000000 +0000       <-----
> Change: 2011-06-10 03:57:39.595385951 +0100
> Birth: -

Hmm, interesting, I wonder how stat is expecting to get the "Birth" time from
the kernel?  We have the crtime in ext4 inodes, so we could be returning it. 

Cheers, Andreas--
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