Deallocation of control->suffix corrupts Heap Memory
pietroborrello opened this issue · comments
The suffix
field in the static rzip_control
structure is initialized to point to global memory in initialize_control
Line 1341 in 64eb4a8
and in the lrzip main.
Line 496 in 6a1600b
However the field is then treated as a heap allocated variable while freeing the rzip_control
variable.
Both in rzip_control_free
Line 1269 in 465afe8
and when setting a new suffix
Line 439 in 465afe8
Impact
Corrupting the heap state may result in an exploitable vulnerability, especially if initialized with optarg
that points to global RW memory.
Fix
It is sufficient to initialize control->suffix
using the return value of a strdup
of the strings.
Good grief! This has been around since v0.1 and rzip before, even before I became involved (v0.19). The initialise function should be used for setting constants or like-size variables, like compression level, etc. Setting control->suffix to equal optarg
is probably a mistake if there will be recursion. I think the dealloc of suffix is incorrect too. It does not need to be. HOWEVER, the ability to pipe input to lrzip
sort of makes recursion obsolete and unnecessary. strdup will work and I'll see about implementing it in lrzip-next
. Thank you
Great, thank you! Will checkout lrzip-next
Fixed in master.
Retrospective note: This seems to have been a CVE assigned, which is CVE-2022-28044.
Hello, is there a simple reproducer for this one?