All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Subject: [PATCH 4/7] xz: avoid overlapping memcpy() with invalid input with in-place decompression
Date: Fri, 19 Nov 2021 11:22:17 +0100	[thread overview]
Message-ID: <389df3f4-5842-0f44-c8a4-42130f51959d@suse.com> (raw)
In-Reply-To: <f96f014c-057a-80a7-b19d-04d7234d3f64@suse.com>

From: Lasse Collin <lasse.collin@tukaani.org>

With valid files, the safety margin described in lib/decompress_unxz.c
ensures that these buffers cannot overlap. But if the uncompressed size
of the input is larger than the caller thought, which is possible when
the input file is invalid/corrupt, the buffers can overlap. Obviously
the result will then be garbage (and usually the decoder will return
an error too) but no other harm will happen when such an over-run occurs.

This change only affects uncompressed LZMA2 chunks and so this
should have no effect on performance.

Link: https://lore.kernel.org/r/20211010213145.17462-2-xiang@kernel.org
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
[Linux commit: 83d3c4f22a36d005b55f44628f46cc0d319a75e8]
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/unxz.c
+++ b/xen/common/unxz.c
@@ -127,7 +127,7 @@
  * memeq and memzero are not used much and any remotely sane implementation
  * is fast enough. memcpy/memmove speed matters in multi-call mode, but
  * the kernel image is decompressed in single-call mode, in which only
- * memcpy speed can matter and only if there is a lot of uncompressible data
+ * memmove speed can matter and only if there is a lot of uncompressible data
  * (LZMA2 stores uncompressible chunks in uncompressed form). Thus, the
  * functions below should just be kept small; it's probably not worth
  * optimizing for speed.
--- a/xen/common/xz/dec_lzma2.c
+++ b/xen/common/xz/dec_lzma2.c
@@ -387,7 +387,14 @@ static void __init dict_uncompressed(str
 
 		*left -= copy_size;
 
-		memcpy(dict->buf + dict->pos, b->in + b->in_pos, copy_size);
+		/*
+		 * If doing in-place decompression in single-call mode and the
+		 * uncompressed size of the file is larger than the caller
+		 * thought (i.e. it is invalid input!), the buffers below may
+		 * overlap and cause undefined behavior with memcpy().
+		 * With valid inputs memcpy() would be fine here.
+		 */
+		memmove(dict->buf + dict->pos, b->in + b->in_pos, copy_size);
 		dict->pos += copy_size;
 
 		if (dict->full < dict->pos)
@@ -397,7 +404,11 @@ static void __init dict_uncompressed(str
 			if (dict->pos == dict->end)
 				dict->pos = 0;
 
-			memcpy(b->out + b->out_pos, b->in + b->in_pos,
+			/*
+			 * Like above but for multi-call mode: use memmove()
+			 * to avoid undefined behavior with invalid input.
+			 */
+			memmove(b->out + b->out_pos, b->in + b->in_pos,
 					copy_size);
 		}
 
@@ -421,6 +432,12 @@ static uint32_t __init dict_flush(struct
 		if (dict->pos == dict->end)
 			dict->pos = 0;
 
+		/*
+		 * These buffers cannot overlap even if doing in-place
+		 * decompression because in multi-call mode dict->buf
+		 * has been allocated by us in this file; it's not
+		 * provided by the caller like in single-call mode.
+		 */
 		memcpy(b->out + b->out_pos, dict->buf + dict->start,
 				copy_size);
 	}



  parent reply	other threads:[~2021-11-19 10:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19 10:20 [PATCH 0/7] (mainly) xz imports from Linux Jan Beulich
2021-11-19 10:21 ` [PATCH 1/7] xz: add fall-through comments to a switch statement Jan Beulich
2021-11-25 16:49   ` Julien Grall
2021-11-25 16:54     ` Julien Grall
2021-11-25 17:03       ` Jan Beulich
2021-11-25 17:13         ` Julien Grall
2021-11-26  7:37           ` Jan Beulich
2021-11-26  9:03             ` Julien Grall
2021-11-26  9:12               ` Jan Beulich
2021-11-26 10:04                 ` Julien Grall
2021-11-26 11:52                   ` Jan Beulich
2021-11-26 12:52                     ` Ian Jackson
2021-12-06 13:44                       ` Jan Beulich
2021-12-06 14:28                         ` Julien Grall
2021-12-06 15:06                           ` Jan Beulich
2021-12-06 16:06                             ` Julien Grall
2021-12-06 16:12                               ` Jan Beulich
2021-12-06 16:21                                 ` Julien Grall
2021-12-06 16:24                                   ` Jan Beulich
2021-12-06 16:30                                     ` Julien Grall
2021-12-06 16:45                                   ` Ian Jackson
2021-12-07  8:55                                     ` Jan Beulich
2021-12-07  9:11                                   ` Jan Beulich
2021-12-07  9:59                                     ` Julien Grall
2021-12-07 10:19                                       ` Jan Beulich
2021-12-07 12:00                                         ` Ian Jackson
2021-12-07 13:30                                           ` Jan Beulich
2021-11-19 10:21 ` [PATCH 2/7] xz: fix XZ_DYNALLOC to avoid useless memory reallocations Jan Beulich
2021-11-25 16:55   ` Julien Grall
2021-11-19 10:21 ` [PATCH 3/7] decompressors: fix spelling mistakes Jan Beulich
2021-11-25 16:57   ` Julien Grall
2021-11-19 10:22 ` Jan Beulich [this message]
2021-11-19 10:22 ` [PATCH 5/7] xz: fix spelling in comments Jan Beulich
2021-11-19 10:23 ` [PATCH 6/7] xz: move s->lzma.len = 0 initialization to lzma_reset() Jan Beulich
2021-11-19 10:23 ` [PATCH 7/7] xz: validate the value before assigning it to an enum variable Jan Beulich
2021-11-19 14:25 ` [PATCH 0/7] (mainly) xz imports from Linux Ian Jackson
2021-11-22  7:10   ` Jan Beulich
2021-12-03 15:35 ` Luca Fancellu

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=389df3f4-5842-0f44-c8a4-42130f51959d@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.