kpartx: Memory bug (`free(): invalid size`)

[danielotero]

Since the last update to 0.14, I found a error by just simply running:

$ sudo kpartx -a disk.img
free(): invalid size
fish: Job 1, 'sudo kpartx -a ../usb.img' terminated by signal SIGABRT (Abort)

Building in debug mode, and tracking a little bit the changes, seems to me like 8c39e60 (from @mwilck) added a "destructor" on uuid:

multipath-tools/kpartx/kpartx.c

Line 197 in 7e5726b

char *uuid __attribute__((cleanup(cleanup_charp))) = NULL;

While the pointer may not always come from the heap:

multipath-tools/kpartx/devmapper.c

Lines 700 to 710 in 7e5726b

	char *nondm_create_uuid(dev_t devt)
	{
	#define NONDM_UUID_BUFLEN (34 + sizeof(NONDM_UUID_PREFIX) + \
	sizeof(NONDM_UUID_SUFFIX))
	static char uuid_buf[NONDM_UUID_BUFLEN];
	snprintf(uuid_buf, sizeof(uuid_buf), "%s_%u:%u_%s",
	NONDM_UUID_PREFIX, major(devt), minor(devt),
	NONDM_UUID_SUFFIX);
	uuid_buf[NONDM_UUID_BUFLEN-1] = '\0';
	return uuid_buf;
	}

I would have uploaded a patch, but I'm not sure how you want to approach the issue. Reverting the commit, fixes the bug, and leaking for a short lived program doesn't seem problematic.

In any case, I think your test-suite needs a couple more cases to cover 😄

[mwilck]

Thanks for the report. This is indeed embarrassing, in particular because the same commit has introduced another, very similar issue already. But somehow I managed to overlook this code path.

[mwilck]

This also affects #134, #135, #136, and #137, which haven't been merged yet, fortunately.

I'll push the same fix there shortly.

[mwilck]

I'm pinning this issue here until we have a full solution.