backport patches from upstream

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 <tobias@stoeckmann.org>
+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
+

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 <tobias@stoeckmann.org>
+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
+

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<yangzhuangzhuang1@huawei.com> - 4.8-2
+- Type:enhancement
+- ID:NA
+- SUG:NA
+- DESC:backport patches from upstream
+
 * Thu Apr 16 2020 chengquan<chengquan3@huawei.com> - 4.8-1
 - Type:enhancement
 - ID:NA