isofs: prevent file time rollover after year 2038

PATCH Applied Arnd Bergmann 5 participants 7 messages Oct 20, 2022 – Oct 25, 2022

Subsystems (3)

Stable branch VFS Isofs filesystem

lore

Share & tools

lore

Arnd Bergmann

author

2022-10-20 16:00 UTC #0 lore raw

PATCH 1/1 isofs: prevent file time rollover after year 2038

From: Thomas Schmitt <[email protected]>

Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.

After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.

Signed-off-by Thomas Schmitt <[email protected]>

Cc [email protected]

Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627

Fixes 34be4dbf87fc ("isofs: fix timestamps beyond 2027")

Fixes 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges")

[arnd: expand changelog text slightly]

Signed-off-by Arnd Bergmann <[email protected]>

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

fs/isofs/isofs.h +1 -1

index dcdc191ed183..c3473ca3f686 100644
@@ -106,7 +106,7 @@ 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);
+extern time64_t iso_date(u8 *, int);
 
 struct inode;		/* To make gcc happy */

fs/isofs/util.c +2 -2

index e88dba721661..348af786a8a4 100644
@@ -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];

Signature · 1 line

2.29.2

Christian Brauner

maintainer Acked-by on v1 1/1

2022-10-21 09:20 UTC #1 lore raw

Quoted 8 lines · Arnd Bergmann

From: Thomas Schmitt <[email protected]>
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.

Quoted 8 lines

Signed-off-by Thomas Schmitt <[email protected]>
Cc [email protected]
Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
Fixes 34be4dbf87fc ("isofs: fix timestamps beyond 2027")
Fixes 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges")
[arnd: expand changelog text slightly]
Signed-off-by Arnd Bergmann <[email protected]>
---

Looks good to me,

Acked-by Christian Brauner (Microsoft) <[email protected]>

Jeff Layton

Reviewed-by on v1 1/1

2022-10-21 12:42 UTC #2 lore raw

In reply to Arnd Bergmann

Quoted 40 lines · Arnd Bergmann

From: Thomas Schmitt <[email protected]>
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Signed-off-by Thomas Schmitt <[email protected]>
Cc [email protected]
Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
Fixes 34be4dbf87fc ("isofs: fix timestamps beyond 2027")
Fixes 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges")
[arnd: expand changelog text slightly]
Signed-off-by Arnd Bergmann <[email protected]>
---
 fs/isofs/isofs.h | 2 +-
 fs/isofs/util.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
fs/isofs/isofs.h +1 -1
index dcdc191ed183..c3473ca3f686 100644
@@ -106,7 +106,7 @@ 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);
+extern time64_t iso_date(u8 *, int);
 
 struct inode;		/* To make gcc happy */
 
fs/isofs/util.c +0 -0
index e88dba721661..348af786a8a4 100644
@@ -16,10 +16,10 @@
  * to GMT.  Thus  we should always be correct.
  */

fs/isofs/util.c line 25

Quoted 10 lines

fs/isofs/util.c +2 -2

 
-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];

Reviewed-by Jeff Layton <[email protected]>

Jan Kara

maintainer

2022-10-24 14:16 UTC #3 lore raw

In reply to Arnd Bergmann

Quoted 8 lines · Arnd Bergmann

From: Thomas Schmitt <[email protected]>
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.

Quoted 7 lines

Signed-off-by Thomas Schmitt <[email protected]>
Cc [email protected]
Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
Fixes 34be4dbf87fc ("isofs: fix timestamps beyond 2027")
Fixes 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges")
[arnd: expand changelog text slightly]
Signed-off-by Arnd Bergmann <[email protected]>

Thanks! I've added the patch to my tree and will push it to Linus.

Honza

Quoted 38 lines

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

fs/isofs/isofs.h +1 -1

index dcdc191ed183..c3473ca3f686 100644
@@ -106,7 +106,7 @@ 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);
+extern time64_t iso_date(u8 *, int);
 
 struct inode;		/* To make gcc happy */

fs/isofs/util.c +2 -2

index e88dba721661..348af786a8a4 100644
@@ -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];

Signature · 1 line

2.29.2

Signature · 2 lines

Jan Kara <[email protected]>
SUSE Labs, CR

Jan Kara

maintainer

2022-10-24 16:16 UTC #4 lore raw

Quoted 17 lines · Jan Kara

Quoted 8 lines · Arnd Bergmann
From: Thomas Schmitt <[email protected]>
Change the return type of function iso_date() from int to time64_t, to avoid truncating to the 1902..2038 date range.
After this patch, the reported timestamps should fall into the range reported in the s_time_min/s_time_max fields.
Quoted 7 lines
Signed-off-by Thomas Schmitt <[email protected]>
Cc [email protected]
Link https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
Fixes 34be4dbf87fc ("isofs: fix timestamps beyond 2027")
Fixes 5ad32b3acded ("isofs: Initialize filesystem timestamp ranges")
[arnd: expand changelog text slightly]
Signed-off-by Arnd Bergmann <[email protected]>

Quoted 1 line

Thanks! I've added the patch to my tree and will push it to Linus.

Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.

Honza

Signature · 2 lines

Jan Kara <[email protected]>
SUSE Labs, CR

Andrew Morton

2022-10-24 22:35 UTC #5 lore raw

Quoted 4 lines · On Mon, 24 Oct 2022 16:51:21 +0200 Jan Kara <[email protected]> wrote:

Quoted 1 line
Thanks! I've added the patch to my tree and will push it to Linus.
Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.

You could have just added it and I'd drop my copy when Stephen tells us of the duplicate. But whatever.

Maybe you owe us an ISOFS MAINTAINERS entry ;)

Jan Kara

maintainer

2022-10-25 09:29 UTC #6 lore raw

Quoted 9 lines · Andrew Morton

Quoted 4 lines · On Mon, 24 Oct 2022 16:51:21 +0200 Jan Kara <[email protected]> wrote:
Quoted 1 line
Thanks! I've added the patch to my tree and will push it to Linus.
Oh, I have noticed Andrew has merged the patch already into his tree. So dropped from mine.
You could have just added it and I'd drop my copy when Stephen tells us of the duplicate. But whatever.

Yeah, I know. But since I've just pulled the patch in I figured it's less work if I just take it out as well ;)

Quoted 1 line

Maybe you owe us an ISOFS MAINTAINERS entry ;)

Yeah, I can see isofs currently has no entry in MAINTAINERS. OK, I'll add some ;)

Honza

Signature · 2 lines

Jan Kara <[email protected]>
SUSE Labs, CR