[BUG] ext4 timestamps corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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

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

Regards,
Akira Fujita

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


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux