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
next prev parent 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).