| Message ID | 20211012185234.3295982-1-nicolas@fjasle.eu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] initramfs: Check timestamp to prevent broken cpio archive | expand |
On Tue 12 Oct 2021 18:52:34 GMT Nicolas Schier wrote: > Cpio format reserves 8 bytes for an ASCII representation of a time_t > timestamp. > While 2106-02-07 06:28:15 UTC (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 > result 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(+) > > -- > Changes v1 to v2: > * add timezone name (UTC) to specific time stamps > * fix typo: results -> result > > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > index 03b21189d58b..584ea45cff70 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 UTC 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", "0x%08x" is at least missing an 'l'. Possibly, showing the invalid timestamp does not make much sense. If someone feeds the string "1607420928" into KBUILD_BUILD_TIMESTAMP, as written in the commit message, $(date -d $KBUILD_BUILD_TIMESTAMP +%s) returns a value that will probably not be helpful. Sorry for the noise; v3 follows. > + default_mtime); > + exit(1); > + } > + > if (argc - optind != 1) { > usage(argv[0]); > exit(1); > -- > 2.30.1
diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c index 03b21189d58b..584ea45cff70 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 UTC 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 UTC (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 result 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(+)