aboutsummaryrefslogtreecommitdiffstats
path: root/usr/include
diff options
context:
space:
mode:
authorNicolas Schier <nicolas@fjasle.eu>2021-10-12 20:12:20 +0000
committerMasahiro Yamada <masahiroy@kernel.org>2021-10-24 13:48:40 +0900
commit4c9d410f32b3fac15ff1197c4b8746da6d11a17e (patch)
tree167560ddf497a9ffeffdbde83a394ebab451b01f /usr/include
parentkbuild: split DEBUG_CFLAGS out to scripts/Makefile.debug (diff)
downloadlinux-dev-4c9d410f32b3fac15ff1197c4b8746da6d11a17e.tar.xz
linux-dev-4c9d410f32b3fac15ff1197c4b8746da6d11a17e.zip
initramfs: Check timestamp to prevent broken cpio archive
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 9:48:48 UTC) 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> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Diffstat (limited to 'usr/include')
0 files changed, 0 insertions, 0 deletions