From 201192e389a6527bdf4f3bf602edda0a5804806d Mon Sep 17 00:00:00 2001 From: John Date: Thu, 4 Jan 2024 15:43:34 +0100 Subject: [PATCH] musl: import upsteam patch to fix oob read in time zone data potential fix for #48056 --- ...x-oob-read-processing-time-zone-data.patch | 80 +++++++++++++++++++ srcpkgs/musl/template | 2 +- 2 files changed, 81 insertions(+), 1 deletion(-) create mode 100644 srcpkgs/musl/patches/fix-oob-read-processing-time-zone-data.patch diff --git a/srcpkgs/musl/patches/fix-oob-read-processing-time-zone-data.patch b/srcpkgs/musl/patches/fix-oob-read-processing-time-zone-data.patch new file mode 100644 index 0000000000000..557cbd7446d9b --- /dev/null +++ b/srcpkgs/musl/patches/fix-oob-read-processing-time-zone-data.patch @@ -0,0 +1,80 @@ +From 3b7b4155570b4b9054465785be2992c92cb7d7b1 Mon Sep 17 00:00:00 2001 +From: Rich Felker +Date: Wed, 9 Feb 2022 17:48:43 -0500 +Subject: fix out-of-bound read processing time zone data with distant-past + dates + +this bug goes back to commit 1cc81f5cb0df2b66a795ff0c26d7bbc4d16e13c6 +where zoneinfo file support was first added. in scan_trans, which +searches for the appropriate local time/dst rule in effect at a given +time, times prior to the second transition time caused the -1 slot of +the index to be read to determine the previous rule in effect. this +memory was always valid (part of another zoneinfo table in the mapped +file) but the byte value read was then used to index another table, +possibly going outside the bounds of the mmap. most of the time, the +result was limited to misinterpretation of the rule in effect at that +time (pre-1900s), but it could produce a crash if adjacent memory was +not readable. + +the root cause of the problem, however, was that the logic for this +code path was all wrong. as documented in the comment, times before +the first transition should be treated as using the lowest-numbered +non-dst rule, or rule 0 if no non-dst rules exist. if the argument is +in units of local time, however, the rule prior to the first +transition is needed to determine if it falls before or after it, and +that's where the -1 index was wrongly used. + +instead, use the documented logic to find out what rule would be in +effect before the first transition, and apply it as the offset if the +argument was given in local time. + +the new code has not been heavily tested, but no longer performs +potentially out-of-bounds accesses, and successfully handles the 1883 +transition from local mean time to central standard time in the test +case the error was reported for. +--- + src/time/__tz.c | 26 ++++++++++++-------------- + 1 file changed, 12 insertions(+), 14 deletions(-) + +diff --git a/src/time/__tz.c b/src/time/__tz.c +index 3e2fcdcb..c34b3eb7 100644 +--- a/src/time/__tz.c ++++ b/src/time/__tz.c +@@ -293,22 +293,20 @@ static size_t scan_trans(long long t, int local, size_t *alt) + n = (index-trans)>>scale; + if (a == n-1) return -1; + if (a == 0) { +- x = zi_read32(trans + (a<