| Message ID | 20211007185900.2801788-1-nicolas@fjasle.eu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | initramfs: Check timestamp to prevent broken cpio archive | expand |
On Fri, Oct 8, 2021 at 3:59 AM Nicolas Schier <nicolas@fjasle.eu> wrote: > > Cpio format reserves 8 bytes for an ASCII representation of a time_t timestamp. > While 2106-02-07 06:28:15 (time_t = 0xffffffff) is still some years in the > future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into > seconds since the epoch, might lead to exceeded cpio timestamp limits that > results in a broken cpio archive. Add timestamp checks to prevent overrun of > the 8-byte cpio header field. Out of curiosity, how did you figure out "2106-02-07 06:28:15" was the overflow point? Is it affected by leap seconds? I got ffff816f $ printf "%x" $(date -d'2106-02-07 06:28:15' +%s) ffff816f > My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed > SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g. > 1607420928 = 2021-12-08 10:48:48) will be interpreted by `date` as a valid date > specification of science fictional times (here: year 160742). Even though this > is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs > cpio format. > > Signed-off-by: Nicolas Schier <nicolas@fjasle.eu> > Cc: Thomas Kühnel <thomas.kuehnel@avm.de> > --- > usr/gen_init_cpio.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > index 03b21189d58b..983dcdd35925 100644 > --- a/usr/gen_init_cpio.c > +++ b/usr/gen_init_cpio.c > @@ -320,6 +320,12 @@ static int cpio_mkfile(const char *name, const char *location, > goto error; > } > > + if (buf.st_mtime > 0xffffffff) { > + fprintf(stderr, "%s: Timestamp exceeds maximum cpio timestamp, clipping.\n", > + location); > + buf.st_mtime = 0xffffffff; > + } > + > filebuf = malloc(buf.st_size); > if (!filebuf) { > fprintf (stderr, "out of memory\n"); > @@ -551,6 +557,17 @@ int main (int argc, char *argv[]) > } > } > > + /* > + * Timestamps after 2106-02-07 06:28:15 have an ascii hex time_t > + * representation that exceeds 8 chars and breaks the cpio header > + * specification. > + */ > + if (default_mtime > 0xffffffff) { > + fprintf(stderr, "ERROR: Timestamp 0x%08x too large for cpio format\n", > + default_mtime); > + exit(1); > + } > + > if (argc - optind != 1) { > usage(argv[0]); > exit(1); > -- > 2.30.1 >
On Tue, Oct 12, 2021 at 11:02:33AM +0900, Masahiro Yamada wrote: > Date: Tue, 12 Oct 2021 11:02:33 +0900 > From: Masahiro Yamada <masahiroy@kernel.org> > To: Nicolas Schier <nicolas@fjasle.eu> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Kbuild > mailing list <linux-kbuild@vger.kernel.org>, Thomas Kühnel > <thomas.kuehnel@avm.de> > Subject: Re: [PATCH] initramfs: Check timestamp to prevent broken cpio > archive > Message-ID: <CAK7LNASDu7RK0vLtx1991abx880DtQHK+U2FK3qKbH5Kcz3ipw@mail.gmail.com> > > On Fri, Oct 8, 2021 at 3:59 AM Nicolas Schier <nicolas@fjasle.eu> wrote: > > > > Cpio format reserves 8 bytes for an ASCII representation of a time_t timestamp. > > While 2106-02-07 06:28:15 (time_t = 0xffffffff) is still some years in the > > future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into > > seconds since the epoch, might lead to exceeded cpio timestamp limits that > > results in a broken cpio archive. Add timestamp checks to prevent overrun of > > the 8-byte cpio header field. > > Out of curiosity, how did you figure out > "2106-02-07 06:28:15" was the overflow point? > Is it affected by leap seconds? > > > I got ffff816f > > > $ printf "%x" $(date -d'2106-02-07 06:28:15' +%s) > ffff816f You have a local time zone offset of -9h? I just did $ TZ=UTC date -d@$((0xffffffff)) Sun Feb 7 06:28:15 UTC 2106 I should have mentioned the time zone info in the commit message. > > My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed > > SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g. > > 1607420928 = 2021-12-08 10:48:48) will be interpreted by `date` as a valid date > > specification of science fictional times (here: year 160742). Even though this > > is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs > > cpio format. > > > > Signed-off-by: Nicolas Schier <nicolas@fjasle.eu> > > Cc: Thomas Kühnel <thomas.kuehnel@avm.de> > > --- > > usr/gen_init_cpio.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > > index 03b21189d58b..983dcdd35925 100644 > > --- a/usr/gen_init_cpio.c > > +++ b/usr/gen_init_cpio.c > > @@ -320,6 +320,12 @@ static int cpio_mkfile(const char *name, const char *location, > > goto error; > > } > > > > + if (buf.st_mtime > 0xffffffff) { > > + fprintf(stderr, "%s: Timestamp exceeds maximum cpio timestamp, clipping.\n", > > + location); > > + buf.st_mtime = 0xffffffff; > > + } > > + > > filebuf = malloc(buf.st_size); > > if (!filebuf) { > > fprintf (stderr, "out of memory\n"); > > @@ -551,6 +557,17 @@ int main (int argc, char *argv[]) > > } > > } > > > > + /* > > + * Timestamps after 2106-02-07 06:28:15 have an ascii hex time_t > > + * representation that exceeds 8 chars and breaks the cpio header > > + * specification. > > + */ > > + if (default_mtime > 0xffffffff) { > > + fprintf(stderr, "ERROR: Timestamp 0x%08x too large for cpio format\n", > > + default_mtime); > > + exit(1); > > + } > > + > > if (argc - optind != 1) { > > usage(argv[0]); > > exit(1); > > -- > > 2.30.1 > > > > > -- > Best Regards > Masahiro Yamada
On Tue, Oct 12, 2021 at 5:29 PM Nicolas Schier <nicolas@fjasle.eu> wrote: > > On Tue, Oct 12, 2021 at 11:02:33AM +0900, Masahiro Yamada wrote: > > Date: Tue, 12 Oct 2021 11:02:33 +0900 > > From: Masahiro Yamada <masahiroy@kernel.org> > > To: Nicolas Schier <nicolas@fjasle.eu> > > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Kbuild > > mailing list <linux-kbuild@vger.kernel.org>, Thomas Kühnel > > <thomas.kuehnel@avm.de> > > Subject: Re: [PATCH] initramfs: Check timestamp to prevent broken cpio > > archive > > Message-ID: <CAK7LNASDu7RK0vLtx1991abx880DtQHK+U2FK3qKbH5Kcz3ipw@mail.gmail.com> > > > > On Fri, Oct 8, 2021 at 3:59 AM Nicolas Schier <nicolas@fjasle.eu> wrote: > > > > > > Cpio format reserves 8 bytes for an ASCII representation of a time_t timestamp. > > > While 2106-02-07 06:28:15 (time_t = 0xffffffff) is still some years in the > > > future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into > > > seconds since the epoch, might lead to exceeded cpio timestamp limits that > > > results in a broken cpio archive. Add timestamp checks to prevent overrun of > > > the 8-byte cpio header field. > > > > Out of curiosity, how did you figure out > > "2106-02-07 06:28:15" was the overflow point? > > Is it affected by leap seconds? > > > > > > I got ffff816f > > > > > > $ printf "%x" $(date -d'2106-02-07 06:28:15' +%s) > > ffff816f > > You have a local time zone offset of -9h? > I just did > > $ TZ=UTC date -d@$((0xffffffff)) > Sun Feb 7 06:28:15 UTC 2106 > > I should have mentioned the time zone info in the commit message. > Ah, time zone! Right, my time zone is JST (+09:00). And, thanks for the update. > > > > > My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed > > > SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g. > > > 1607420928 = 2021-12-08 10:48:48) will be interpreted by `date` as a valid date > > > specification of science fictional times (here: year 160742). Even though this > > > is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs > > > cpio format. > > > > > > Signed-off-by: Nicolas Schier <nicolas@fjasle.eu> > > > Cc: Thomas Kühnel <thomas.kuehnel@avm.de> > > > --- > > > usr/gen_init_cpio.c | 17 +++++++++++++++++ > > > 1 file changed, 17 insertions(+) > > > > > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > > > index 03b21189d58b..983dcdd35925 100644 > > > --- a/usr/gen_init_cpio.c > > > +++ b/usr/gen_init_cpio.c > > > @@ -320,6 +320,12 @@ static int cpio_mkfile(const char *name, const char *location, > > > goto error; > > > } > > > > > > + if (buf.st_mtime > 0xffffffff) { > > > + fprintf(stderr, "%s: Timestamp exceeds maximum cpio timestamp, clipping.\n", > > > + location); > > > + buf.st_mtime = 0xffffffff; > > > + } > > > + > > > filebuf = malloc(buf.st_size); > > > if (!filebuf) { > > > fprintf (stderr, "out of memory\n"); > > > @@ -551,6 +557,17 @@ int main (int argc, char *argv[]) > > > } > > > } > > > > > > + /* > > > + * Timestamps after 2106-02-07 06:28:15 have an ascii hex time_t > > > + * representation that exceeds 8 chars and breaks the cpio header > > > + * specification. > > > + */ > > > + if (default_mtime > 0xffffffff) { > > > + fprintf(stderr, "ERROR: Timestamp 0x%08x too large for cpio format\n", > > > + default_mtime); > > > + exit(1); > > > + } > > > + > > > if (argc - optind != 1) { > > > usage(argv[0]); > > > exit(1); > > > -- > > > 2.30.1 > > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > -- > epost|xmpp: nicolas@fjasle.eu irc://oftc.net/nsc > ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f > -- frykten for herren er opphav til kunnskap --
diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c index 03b21189d58b..983dcdd35925 100644 --- a/usr/gen_init_cpio.c +++ b/usr/gen_init_cpio.c @@ -320,6 +320,12 @@ static int cpio_mkfile(const char *name, const char *location, goto error; } + if (buf.st_mtime > 0xffffffff) { + fprintf(stderr, "%s: Timestamp exceeds maximum cpio timestamp, clipping.\n", + location); + buf.st_mtime = 0xffffffff; + } + filebuf = malloc(buf.st_size); if (!filebuf) { fprintf (stderr, "out of memory\n"); @@ -551,6 +557,17 @@ int main (int argc, char *argv[]) } } + /* + * Timestamps after 2106-02-07 06:28:15 have an ascii hex time_t + * representation that exceeds 8 chars and breaks the cpio header + * specification. + */ + if (default_mtime > 0xffffffff) { + fprintf(stderr, "ERROR: Timestamp 0x%08x too large for cpio format\n", + default_mtime); + exit(1); + } + if (argc - optind != 1) { usage(argv[0]); exit(1);
Cpio format reserves 8 bytes for an ASCII representation of a time_t timestamp. While 2106-02-07 06:28:15 (time_t = 0xffffffff) is still some years in the future, a poorly chosen date string for KBUILD_BUILD_TIMESTAMP, converted into seconds since the epoch, might lead to exceeded cpio timestamp limits that results in a broken cpio archive. Add timestamp checks to prevent overrun of the 8-byte cpio header field. My colleague Thomas Kühnel discovered the behaviour, when we accidentally fed SOURCE_DATE_EPOCH to KBUILD_BUILD_TIMESTAMP as is: some timestamps (e.g. 1607420928 = 2021-12-08 10:48:48) will be interpreted by `date` as a valid date specification of science fictional times (here: year 160742). Even though this is bad input for KBUILD_BUILD_TIMESTAMP, it should not break the initramfs cpio format. Signed-off-by: Nicolas Schier <nicolas@fjasle.eu> Cc: Thomas Kühnel <thomas.kuehnel@avm.de> --- usr/gen_init_cpio.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)