reopen 767295
thanks
The 4.4.1-4 release only included one related fix there are actually two
more:
commit 379b351889a8f02abe30a06e2ce9ba8b381b91ab
Author: Ian Campbell <[email protected]>
Date: Thu Nov 6 13:00:31 2014 +0000
tools: libxl: do not leak diskpath during local disk attach
libxl__device_disk_local_initiate_attach is assigning dls->diskpath
with a
strdup of the device path. This is then passed to the callback, e.g.
parse_bootloader_result but bootloader_cleanup will not free it.
Since the callback is within the scope of the (e)gc and therefore
doesn't need
to be malloc'd, a gc'd alloc will do. All other assignments to this
field use
the gc.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
Reported-by: Gedalya <[email protected]>
Signed-off-by: Ian Campbell <[email protected]>
Acked-by: Ian Jackson <[email protected]>
Acked-by: Wei Liu <[email protected]>
commit 8f4023dd7d77de7b2c1af77e86637202a33f948a
Author: Ian Campbell <[email protected]>
Date: Thu Nov 20 15:48:47 2014 +0000
libxc: don't leak buffer containing the uncompressed PV kernel
The libxc xc_dom_* infrastructure uses a very simple malloc memory
pool which
is freed by xc_dom_release. However the various xc_try_*_decode
routines (other
than the gzip one) just use plain malloc/realloc and therefore the
buffer ends
up leaked.
The memory pool currently supports mmap'd buffers as well as a
directly
allocated buffers, however the try decode routines make use of
realloc and do
not fit well into this model. Introduce a concept of an external
memory block
to the memory pool and provide an interface to register such memory.
The mmap_ptr and mmap_len fields of the memblock tracking struct
lose their
mmap_ prefix since they are now also used for external memory
blocks.
We are only seeing this now because the gzip decoder doesn't leak
and it's only
relatively recently that kernels in the wild have switched to better
compression.
This is https://bugs.debian.org/767295
Reported by: Gedalya <[email protected]>
Signed-off-by: Ian Campbell <[email protected]>
Reviewed-by: Wei Liu <[email protected]>
Which the actual leaks discovered here (of which the second is the far
larger).
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
