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  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:	Sat, 16 Jun 2007 23:05:27 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Fw: [Bugme-new] [Bug 8643] New: Bug with negative timestamps on
 64bit machines


someone ort to fix this


Begin forwarded message:

Date: Sat, 16 Jun 2007 17:50:35 -0700 (PDT)
From: bugme-daemon@...zilla.kernel.org
To: bugme-new@...ts.osdl.org
Subject: [Bugme-new] [Bug 8643] New: Bug with negative timestamps on 64bit machines


http://bugzilla.kernel.org/show_bug.cgi?id=8643

           Summary: Bug with negative timestamps on 64bit machines
           Product: File System
           Version: 2.5
     KernelVersion: 2.6.21-1.3228.fc7
          Platform: All
        OS/Version: Linux
              Tree: Fedora
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext3
        AssignedTo: akpm@...l.org
        ReportedBy: markus.mottl@...il.com


Most recent kernel where this bug did not occur:
Distribution: Fedora Core 7
Hardware Environment: AMD Athlon 64
Software Environment:
Problem Description:

Negative timestamps (i.e. before 1970) are incorrectly handled due to some
obvious 64bit issues.  They show up normally as long as the cache has not been
purged.

Steps to reproduce:

Touch a file in an ext3-file system with a negative timestamp, e.g.:

  # touch -t 196901010000 /opt/foo

Unless you have been writing a lot of data to this partition after the last
command, the next one should display the following:

  #  ls -l /opt/foo
  -rw-r--r-- 1 root root 0 1969-01-01 00:00 /opt/foo

This is still correct.  But now we purge the file system cache by unmounting
and mounting the partition again:

  # umount /opt/foo
  # mount /opt/foo

Now the timestamp will be corrupted:

  # ls -l /opt/foo 
  -rw-r--r-- 1 root root 0 2105-02-07 06:28 /opt/foo

It seems obvious that the upper 32 bits of the 64 bits representing the time
stamp get lost, which explains the above observation.

On 32bit architectures there is no such problem.  I haven't managed to
reproduce this problem with other file systems (e.g. XFS).


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-
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

Powered by blists - more mailing lists