linux-ext4 - Re: Y2038 bug in ext4 recently

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: <CABeXuvqtDdtjgjEznXPgdUfaZiG-KJ3AURpT_AuUACcPATaoDw@mail.gmail.com>
Date:   Thu, 17 Aug 2017 18:23:26 -0700
From:   Deepa Dinamani <deepa.kernel@...il.com>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     "Theodore Ts'o" <tytso@....edu>, Arnd Bergmann <arnd@...db.de>,
        Wang Shilong <wshilong@....com>,
        Wang Shilong <wangshilong1991@...il.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        Shuichi Ihara <sihara@....com>, Li Xi <lixi@....com>,
        Jan Kara <jack@...e.cz>
Subject: Re: Y2038 bug in ext4 recently_deleted() function

> Strange, I never even knew recently_deleted() existed, even though it was
> added to the tree 4 years ago yesterday.  It looks like this is only used
> with the no-journal code, which I don't really interact with.
>
> One thing I did notice when looking at it is that there is a Y2038 bug in
> recently_deleted(), as it is comparing 32-bit i_dtime directly with 64-bit
> get_seconds().

I don't think dtime has widened on the disk layout for ext4 according
to https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout. So I am
not sure how fixing the internal implementation would be useful until
we do that. Is there a plan for that?

As far as get_seconds() is concerned, get_seconds() returns unsigned
long which is 64 bits on a 64 bit arch and 32 bit on a 32 bit arch.
Since dtime variable is declared as unsigned long in this function,
same holds for the size of this variable.

There is no y2038 problem on a 64 bit machine.

So moving to the case of a 32 bit machine:

get_seconds() can return values until year 2106. And, recentcy at max
can only be 35. Analyzing the current line:

if (dtime && (dtime < now) && (now < dtime + recentcy))

The above equation should work fine at least until 35 seconds before
y2038 deadline.

-Deepa