GNU bug report logs - #39166
[PATCH] sed: handle very long input lines with R

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Tobias Stoeckmann <tobias <at> stoeckmann.org>
Subject: bug#39166: closed (Re: bug#39166: [PATCH] sed: handle very long
 input lines with R)
Date: Sat, 18 Jan 2020 16:15:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#39166: [PATCH] sed: handle very long input lines with R

which was filed against the sed package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 39166 <at> debbugs.gnu.org.

-- 
39166: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39166
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Tobias Stoeckmann <tobias <at> stoeckmann.org>
Cc: 39166-done <at> debbugs.gnu.org
Subject: Re: bug#39166: [PATCH] sed: handle very long input lines with R
Date: Sat, 18 Jan 2020 08:14:23 -0800

[Message part 3 (text/plain, inline)]

On Fri, Jan 17, 2020 at 1:29 PM Tobias Stoeckmann <tobias <at> stoeckmann.org> wrote:
> It is possible to trigger an out of boundary memory access when
> using the sed command R with an input file containing very long
> lines.

Thank you for another fine patch.
I've adjusted the commit log and will push the attached later today.

[sed-2G-R.diff (application/octet-stream, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Tobias Stoeckmann <tobias <at> stoeckmann.org>
To: bug-sed <at> gnu.org
Subject: [PATCH] sed: handle very long input lines with R
Date: Fri, 17 Jan 2020 21:28:28 +0100

It is possible to trigger an out of boundary 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 boundary 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.

Signed-off-by: Tobias Stoeckmann <tobias <at> stoeckmann.org>
---
 sed/execute.c | 2 +-
 1 file changed, 1 insertion(+), 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);
-- 
2.25.0

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.