public inbox for
help / color / mirror / Atom feed
Subject: LVM2 ./WHATS_NEW lib/format1/import-extents.c
Date: Wed, 30 Mar 2011 12:30:00 -0000	[thread overview]
Message-ID: <> (raw)

CVSROOT:	/cvs/lvm2
Module name:	LVM2
Changes by:	2011-03-30 12:30:40

Modified files:
	.              : WHATS_NEW 
	lib/format1    : import-extents.c 

Log message:
	Fix reading of unitialized memory
	Could be reached via few of our lvm2 test cases:
	==11501== Invalid read of size 8
	==11501==    at 0x49B2E0: _area_length (import-extents.c:204)
	==11501==    by 0x49B40C: _read_linear (import-extents.c:222)
	==11501==    by 0x49B952: _build_segments (import-extents.c:323)
	==11501==    by 0x49B9A0: _build_all_segments (import-extents.c:334)
	==11501==    by 0x49BB4C: import_extents (import-extents.c:364)
	==11501==    by 0x497655: _format1_vg_read (format1.c:217)
	==11501==    by 0x47E43E: _vg_read (metadata.c:2901)
	cut from
	pvcreate -M1 $(cat DEVICES)
	vgcreate -M1 -c n $vg $(cat DEVICES)
	lvcreate -l1 -n $lv1 $vg $dev1
	Idea of the fix is rather defensive - to allocate one extra element
	to 'map' array which is then used in _area_length() - where the
	loop checks, whether next map entry is continuous.
	By placing there always one extra zero entry -
	we fix the read of unallocated memory, and we make sure the data would
	not make a continous block.
	FIXME: there could be a problem if some special broken lvm1 data would be imported.
	As the format1 is currently not really used - leave it for future fix
	and use this small hotfix for now.


--- LVM2/WHATS_NEW	2011/03/29 21:57:56	1.1962
+++ LVM2/WHATS_NEW	2011/03/30 12:30:39	1.1963
@@ -1,5 +1,6 @@
 Version 2.02.85 - 
+  Fix reading of unallocated memory in lvm1 format import function.
   Replace several strncmp() calls with id_equal().
   Fix lvmcache_info transfer to orphan_vginfo in _lvmcache_update_vgname().
   Fix -Wold-style-definition gcc warnings.
--- LVM2/lib/format1/import-extents.c	2010/04/08 00:28:57	1.39
+++ LVM2/lib/format1/import-extents.c	2011/03/30 12:30:39	1.40
@@ -63,8 +63,12 @@
 		lvm->lv = ll->lv;
+		/*
+		 * Alloc 1 extra element, so the loop in _area_length() and
+		 * _check_stripe() finds the last map member as noncontinuous.
+		 */
 		if (!(lvm->map = dm_pool_zalloc(mem, sizeof(*lvm->map)
-					     * ll->lv->le_count)))
+					     * (ll->lv->le_count + 1))))
 		if (!dm_hash_insert(maps, ll->lv->name, lvm))

             reply	other threads:[~2011-03-30 12:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 12:30 zkabelac [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-03-15 13:38 agk
2005-12-19 16:28 agk

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).