diff --git a/backport-sed-handle-very-long-execution-lines-tiny-change.patch b/backport-sed-handle-very-long-execution-lines-tiny-change.patch new file mode 100644 index 0000000000000000000000000000000000000000..1a669629fc12bfabf3c846bf91ba84f424658753 --- /dev/null +++ b/backport-sed-handle-very-long-execution-lines-tiny-change.patch @@ -0,0 +1,59 @@ +From 61b5e58f18f152636a77c872dc39281bfb8bf90d Mon Sep 17 00:00:00 2001 +From: Tobias Stoeckmann +Date: Fri, 17 Jan 2020 20:49:33 +0100 +Subject: [PATCH] sed: handle very long execution lines (tiny change) + +If sed is called with an excessively long execution line, then it is +prone to an out of bounds memory access. + +The problem is that the length of the execution line, which is a +size_t, is temporarily stored in an int. This means that on systems +which have a 64 bit size_t and a 32 bit int (e.g. linux amd64) an +execution line which exceeds 2 GB will overflow int. If it is just +slightly larger than 2 GB, the negative int value is used as an +array index to finish the execution line string with '\0' which +therefore triggers the out of bounds access. + +This problem is probably never triggered in reality, but can be +provoked like this (given that 'e' support is compiled in): + +$ dd if=/dev/zero bs=1M count=2049 | tr '\0' e > e-command.txt +$ sed -f e-command.txt /etc/fstab +Segmentation fault (core dumped) + +Also adjust another int/size_t conversion, even though it is a +purely cosmetic change, because it can never be larger than 4096. + +* sed/execute.c (execute_program) [case 'e']: Declare cmd_length +to be of type size_t, not int. Likewise for "n" just below. +* NEWS (Bug fixes): Mention it. +This addresses https://bugs.gnu.org/39165 +--- + sed/execute.c | 4 ++-- + 1 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/sed/execute.c b/sed/execute.c +index c5f07cc..8f43f2e 100644 +--- a/sed/execute.c ++++ b/sed/execute.c +@@ -1347,7 +1347,7 @@ execute_program (struct vector *vec, struct input *input) + panic (_("`e' command not supported")); + #else + FILE *pipe_fp; +- int cmd_length = cur_cmd->x.cmd_txt.text_length; ++ size_t cmd_length = cur_cmd->x.cmd_txt.text_length; + line_reset (&s_accum, NULL); + + if (!cmd_length) +@@ -1367,7 +1367,7 @@ execute_program (struct vector *vec, struct input *input) + + { + char buf[4096]; +- int n; ++ size_t n; + while (!feof (pipe_fp)) + if ((n = fread (buf, sizeof (char), 4096, pipe_fp)) > 0) + { +-- +1.8.3.1 + diff --git a/backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch b/backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch new file mode 100644 index 0000000000000000000000000000000000000000..555e823c4b47f4e47c1ac08fa408a0bde889ff9f --- /dev/null +++ b/backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch @@ -0,0 +1,58 @@ +From acabfdb582330345c05e0500d302e9e99f3eb5e9 Mon Sep 17 00:00:00 2001 +From: Tobias Stoeckmann +Date: Fri, 17 Jan 2020 21:28:28 +0100 +Subject: [PATCH] sed: handle very long input lines with R (tiny change) + +It is possible to trigger an out of bounds memory access when +using the sed command R with an input file containing very long +lines. + +The problem is that the line length of parsed file is returned as +a size_t by ck_getdelim, but temporarily stored in an int and +then converted back into a size_t. On systems like amd64, on which +this problem can be triggered, size_t and int have different sizes. + +If the input line is longer than 2 GB (which is parseable on amd64 +or other 64 bit systems), this means that the temporarily stored +int turns negative. Converting the negative int back into a size_t +will lead to an excessively large size_t, as the conversion leads to +a lot of leading 1 bits. + +Eventually ck_fwrite is called with this huge size_t which in turn +will lead to an out of bounds access on amd64 systems -- after all +the parsed text was just a bit above 2 GB, not near SIZE_MAX. + +You can trigger this issue with GNU sed on OpenBSD like this: + +$ dd if=/dev/zero bs=1M count=2049 | tr '\0' e > long.txt +$ sed Rlong.txt /etc/fstab +Segmentation fault (core dumped) + +I was unable to trigger the bug on a Linux system with glibc due to +a bug in glibc's fwrite implementation -- it leads to a short write +and sed treats that correctly as an error. + +* sed/execute.c (execute_program) [case 'R']: Declare result +to be of type size_t, not int. +* NEWS (Bug fixes): Mention it. +This addresses https://bugs.gnu.org/39166 +--- + sed/execute.c | 2 +- + 1 files changed, 1 insertions(+), 1 deletion(-) + +diff --git a/sed/execute.c b/sed/execute.c +index 8f43f2e..f94b125 100644 +--- a/sed/execute.c ++++ b/sed/execute.c +@@ -1518,7 +1518,7 @@ execute_program (struct vector *vec, struct input *input) + struct append_queue *aq; + size_t buflen; + char *text = NULL; +- int result; ++ size_t result; + + result = ck_getdelim (&text, &buflen, buffer_delimiter, + cur_cmd->x.inf->fp); +-- +1.8.3.1 + diff --git a/sed.spec b/sed.spec index 142374b969fd9d3bcd7e595ffd33eb548c239208..f68017613fe185af217f05e100189569c0eee315 100644 --- a/sed.spec +++ b/sed.spec @@ -1,12 +1,15 @@ Name: sed Version: 4.8 -Release: 1 +Release: 2 Summary: non-interactive command-line text editor License: GPLv3+ URL: https://www.gnu.org/software/sed/ Source0: http://ftp.gnu.org/gnu/sed/%{name}-%{version}.tar.xz +Patch0: backport-sed-handle-very-long-execution-lines-tiny-change.patch +Patch1: backport-sed-handle-very-long-input-lines-with-R-tiny-change.patch + BuildRequires: gzip automake autoconf gcc BuildRequires: glibc-devel libselinux-devel libacl-devel perl-Getopt-Long Provides: /bin/sed @@ -47,6 +50,12 @@ make %{?_smp_mflags} %{_mandir}/man1/*.1.gz %changelog +* Fri Jan 15 2021 yangzhuangzhuang - 4.8-2 +- Type:enhancement +- ID:NA +- SUG:NA +- DESC:backport patches from upstream + * Thu Apr 16 2020 chengquan - 4.8-1 - Type:enhancement - ID:NA