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
| ||
|
Date: Tue, 22 Aug 2017 17:18:14 +0200 From: Arnd Bergmann <arnd@...db.de> To: Andreas Dilger <adilger@...ger.ca> Cc: Deepa Dinamani <deepa.kernel@...il.com>, "Theodore Ts'o" <tytso@....edu>, 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 On Fri, Aug 18, 2017 at 6:09 PM, Andreas Dilger <adilger@...ger.ca> wrote: > >>>> 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. >>> >>> Since it's all unsigned arithmetic, it should be fine until 2106. >>> However, we should get rid of get_seconds() long before then >>> and use ktime_get_real_seconds() instead, as most other users >>> of get_seconds() are (more) broken. >> >> Dtime on disk representation again breaks this for certain values in >> 2038 even though everything is unsigned. >> >> I was just saying that whatever we do here depends on how dtime on >> disk is interpreted. >> >> Agree that ktime_get_real_seconds() should be used here. But, the way >> we handle new values would rely on this new interpretation of dtime. >> Also, using time64_t variables on stack only matters after this. Once >> the types are corrected, maybe the comparison expression need not >> change at all (after new dtime interpretation is in place). > > There will not be a new dtime format on disk, but since the calculation > here only depends on relative times (within a few minutes), then it would > be fine to use only 32-bit timestamps, and truncate off the high bits > from get_seconds()/ktime_get_real_seconds(). Agreed. Are you planning to apply your fix for it then? I think your first suggestion is all we need, aside from the three minor comments I had. Arnd
Powered by blists - more mailing lists