All of lore.kernel.org
 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: 14+ 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
2020-12-09 15:58 kernel " Andy Shevchenko
2020-12-09 16:07 ` Lars-Peter Clausen
2020-12-09 16:33   ` Andy Shevchenko
2020-12-13 15:15     ` Jonathan Cameron

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.