kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: kernelnewbies@kernelnewbies.org
Cc: ebashinskii@mail.ru
Subject: Re: Kernel bug tracker
Date: Sun, 05 Sep 2021 13:48:37 +0200	[thread overview]
Message-ID: <292361858473424095@scdbackup.webframe.org> (raw)
In-Reply-To: <1630836614.781283386@f753.i.mail.ru>

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@vger.kernel.org and
linux-scsi@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@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@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@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


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2021-09-05 11:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1630659351.685242253@f502.i.mail.ru>
2021-09-03 11:00 ` Kernel bug tracker Thomas Schmitt
2021-09-03 15:55   ` Valdis Klētnieks
2021-09-03 16:58     ` Thomas Schmitt
2021-09-05 10:10       ` Re[2]: " Adverg Ebashinskii
2021-09-05 11:48         ` Thomas Schmitt [this message]
2021-09-05 12:08           ` Thomas Schmitt
2021-09-06  8:11           ` Re[2]: " Adverg Ebashinskii
2021-09-06  9:04             ` Thomas Schmitt
2021-09-05 11:57         ` Thomas Schmitt
     [not found] <1630220663.155756289@f748.i.mail.ru>
2021-08-29  8:50 ` Anatoly Pugachev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=292361858473424095@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=ebashinskii@mail.ru \
    --cc=kernelnewbies@kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).