From: "Volodymyr G. Lukiianyk" <volodymyrgl@gmail.com>
To: Greg Ungerer <gerg@uclinux.org>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] uclinux: fix gzip header parsing in binfmt_flat.c
Date: Tue, 26 Aug 2008 20:52:03 +0300 [thread overview]
Message-ID: <48B442C3.2000309@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
There are off-by-one errors in decompress_exec() when calculating the length of
optional "original file name" and "comment" fields: the "ret" index is not
incremented when terminating '\0' character is reached. The check of the buffer
overflow (after an "extra-field" length was taken into account) is also fixed.
Signed-off-by: Volodymyr G Lukiianyk <volodymyrgl@gmail.com>
---
I've encountered this off-by-one error when tried to reuse gzip-header-parsing
part of the decompress_exec() function. There was an "original file name" field
in the payload (with miscalculated length) and zlib_inflate() returned
Z_DATA_ERROR. But after the fix similar to this one all worked fine.
WARNING: the proposed patch wasn't properly tested.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: binfmt_flat_decompress_fix.diff --]
[-- Type: text/x-patch; name="binfmt_flat_decompress_fix.diff", Size: 1092 bytes --]
^[[1mdiff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c^[[m
^[[1mindex dfc0197..ccb781a 100644^[[m
^[[1m--- a/fs/binfmt_flat.c^[[m
^[[1m+++ b/fs/binfmt_flat.c^[[m
^[[36m@@ -229,13 +229,13 @@ static int decompress_exec(
^[[m ret = 10;
^[[m if (buf[3] & EXTRA_FIELD) {
^[[m ret += 2 + buf[10] + (buf[11] << 8);
^[[m^[[31m- if (unlikely(LBUFSIZE == ret)) {
^[[m^[[32m+^[[m ^[[32mif (unlikely(LBUFSIZE <= ret)) {^[[m
DBG_FLT("binfmt_flat: buffer overflow (EXTRA)?\n");
^[[m goto out_free_buf;
^[[m }
^[[m }
^[[m if (buf[3] & ORIG_NAME) {
^[[m^[[31m- for (; ret < LBUFSIZE && (buf[ret] != 0); ret++)
^[[m^[[32m+^[[m ^[[32mwhile (ret < LBUFSIZE && buf[ret++] != 0)^[[m
;
^[[m if (unlikely(LBUFSIZE == ret)) {
^[[m DBG_FLT("binfmt_flat: buffer overflow (ORIG_NAME)?\n");
^[[m^[[36m@@ -243,7 +243,7 @@ static int decompress_exec(
^[[m }
^[[m }
^[[m if (buf[3] & COMMENT) {
^[[m^[[31m- for (; ret < LBUFSIZE && (buf[ret] != 0); ret++)
^[[m^[[32m+^[[m ^[[32mwhile (ret < LBUFSIZE && buf[ret++] != 0)^[[m
;
^[[m if (unlikely(LBUFSIZE == ret)) {
^[[m DBG_FLT("binfmt_flat: buffer overflow (COMMENT)?\n");
^[[m
next reply other threads:[~2008-08-26 17:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-26 17:52 Volodymyr G. Lukiianyk [this message]
2008-08-26 17:57 ` [PATCH] uclinux: fix gzip header parsing in binfmt_flat.c Volodymyr G. Lukiianyk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48B442C3.2000309@gmail.com \
--to=volodymyrgl@gmail.com \
--cc=gerg@uclinux.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.