Kernel bug tracker

Thomas Schmitt scdbackup at gmx.net
Sun Sep 5 07:48:37 EDT 2021


Hi,

Adverg Ebashinskii wrote:
> If you could share your patch here to understand the problem better I would
> gladly dig into it.

Ok. Here is the simple one. The other comes in a separate mail.

The following texts stem from git format-patch. If submitting for real,
i would send them by git send-email to linux-kernel at vger.kernel.org and
linux-scsi at vger.kernel.org.
(The latter because Jens Axboe committed a few isofs changes in the past
and because isofs is historically related to sr and cdrom.)

========================================================================
0000-cover-letter.patch

From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001
From: Thomas Schmitt <scdbackup at gmx.net>
Date: Mon, 21 Sep 2020 18:20:14 +0200
Subject: [PATCH 0/1] isofs: prevent file time rollover after year 2038

The time values in struct inode of isofs result from calls to function
iso_date() in isofs/util.c, which returns seconds in the range of signed
int. This will rollover in 2038.
ISO 9660 directory record timestamps are good for up to year 2155.
(ECMA-119 9.1.5: 1900 + 255)

The only callers of iso_date() are in isofs/inode.c and isofs/rock.c
and put the result into struct inode.i_{a,c,m}time.tv_sec which is
of type time64_t.
The time value of iso_date() essentially stems from mktime64().

So return type time64_t is appropriate for iso_date().

--------------------------------------------------------------------------
Demonstration of the problem:

Create an ISO 9660 filesystem with file date in 2040, using file /bin/true
as victim payload:

  xorriso -outdev /tmp/test_date.iso \
          -blank as_needed \
          -map /bin/true /victim \
          -alter_date m 'Oct 01 22:06:12 2040' /victim --

Inspect the current representation by isofs:

  mount /tmp/test_date.iso /mnt/iso
  ls -l /mnt/iso/victim

This yields with int iso_date():

  ... Aug 26  1904 /mnt/iso/victim

After changing the type of iso_date() to time64_t:

  ... Oct  1  2040 /mnt/iso/victim

For completeness i tested the last possible second:

  xorriso ... -alter_date m 'Dec 31 23:59:59 2155' /victim --

and got properly:

  ... Dec 31  2155 /mnt/iso/victim

(When reproducing this it might be to wise to use December 30, to avoid
any potential timezone problems.)

--------------------------------------------------------------------------

Have a nice day :)

Thomas

Thomas Schmitt (1):
  isofs: prevent file time rollover after year 2038

 fs/isofs/isofs.h | 3 ++-
 fs/isofs/util.c  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

--
2.20.1

========================================================================
0001-isofs-prevent-file-time-rollover-after-year-2038.patch

From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001
From: Thomas Schmitt <scdbackup at gmx.net>
Date: Mon, 21 Sep 2020 18:20:06 +0200
Subject: [PATCH 1/1] isofs: prevent file time rollover after year 2038

Change the return type of function iso_date() from int to time64_t.

Signed-off-by: Thomas Schmitt <scdbackup at gmx.net>
---
 fs/isofs/isofs.h | 3 ++-
 fs/isofs/util.c  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h
index 055ec6c586f7..527c0db72ff9 100644
--- a/fs/isofs/isofs.h
+++ b/fs/isofs/isofs.h
@@ -107,7 +107,8 @@ static inline unsigned int isonum_733(u8 *p)
 	/* Ignore bigendian datum due to broken mastering programs */
 	return get_unaligned_le32(p);
 }
-extern int iso_date(u8 *, int);
+
+time64_t iso_date(u8 *, int);

 struct inode;		/* To make gcc happy */

diff --git a/fs/isofs/util.c b/fs/isofs/util.c
index e88dba721661..348af786a8a4 100644
--- a/fs/isofs/util.c
+++ b/fs/isofs/util.c
@@ -16,10 +16,10 @@
  * to GMT.  Thus  we should always be correct.
  */

-int iso_date(u8 *p, int flag)
+time64_t iso_date(u8 *p, int flag)
 {
 	int year, month, day, hour, minute, second, tz;
-	int crtime;
+	time64_t crtime;

 	year = p[0];
 	month = p[1];
--
2.20.1

========================================================================

Have a nice day :)

Thomas




More information about the Kernelnewbies mailing list