Hi,
I am a security researcher, my name is Dongyang Zhan. I found a potential bug.
I hope you can help me to confirm it.
Thank you.
Possible memory leak in Linux 4.10.17. The function unxz() in
/lib/decompress_unxz.c forgets to free the pointer 'in', when the
statement if (fill == NULL && flush == NULL) is true.
Source code and comments:
if (in == NULL) {
must_free_in = true;
in = malloc(XZ_IOBUF_SIZE);
if (in == NULL)
goto error_alloc_in;
}
b.in = in;
b.in_pos = 0;
b.in_size = in_size;
b.out_pos = 0;
if (fill == NULL && flush == NULL) {
ret = xz_dec_run(s, &b); // When this statement is true, it will jumps
to the switch statement. But the allocated 'in' is not freed before
return.
} else {
.....
}
.....
switch (ret) {
case XZ_STREAM_END:
return 0;
case XZ_MEM_ERROR:
/* This can occur only in multi-call mode. */
error("XZ decompressor ran out of memory");
break;
case XZ_FORMAT_ERROR:
error("Input is not in the XZ format (wrong magic bytes)");
break;
case XZ_OPTIONS_ERROR:
error("Input was encoded with settings that are not "
"supported by this XZ decoder");
break;
case XZ_DATA_ERROR:
case XZ_BUF_ERROR:
error("XZ-compressed data is corrupt");
break;
default:
error("Bug in the XZ decompressor");
break;
}
return -1;
....
On 5/3/20 12:23 AM, Dongyang Zhan wrote:
> Hi,
>
> I am a security researcher, my name is Dongyang Zhan. I found a potential bug.
>
> I hope you can help me to confirm it.
>
> Thank you.
>
> Possible memory leak in Linux 4.10.17. The function unxz() in
It would be more helpful if you could focus on more recent/current
source code. If someone makes a patch for current source code and
it needs to be backported to older kernels, then that would [normally]
happen.
> /lib/decompress_unxz.c forgets to free the pointer 'in', when the
> statement if (fill == NULL && flush == NULL) is true.
Adding xz contributor to email.
I think that you are correct. (I am looking at 5.7-rc4.)
However, I don't see any calls to __decompress() in the
Linux kernel that pass a first argument of NULL, so while
the code in unxz() could be fixed, we aren't currently leaking
any memory AFAICT.
> Source code and comments:
>
> if (in == NULL) {
> must_free_in = true;
> in = malloc(XZ_IOBUF_SIZE);
> if (in == NULL)
> goto error_alloc_in;
> }
>
> b.in = in;
> b.in_pos = 0;
> b.in_size = in_size;
> b.out_pos = 0;
>
> if (fill == NULL && flush == NULL) {
> ret = xz_dec_run(s, &b); // When this statement is true, it will jumps
> to the switch statement. But the allocated 'in' is not freed before
> return.
> } else {
> .....
> }
> .....
> switch (ret) {
> case XZ_STREAM_END:
> return 0;
>
> case XZ_MEM_ERROR:
> /* This can occur only in multi-call mode. */
> error("XZ decompressor ran out of memory");
> break;
>
> case XZ_FORMAT_ERROR:
> error("Input is not in the XZ format (wrong magic bytes)");
> break;
>
> case XZ_OPTIONS_ERROR:
> error("Input was encoded with settings that are not "
> "supported by this XZ decoder");
> break;
>
> case XZ_DATA_ERROR:
> case XZ_BUF_ERROR:
> error("XZ-compressed data is corrupt");
> break;
>
> default:
> error("Bug in the XZ decompressor");
> break;
> }
>
> return -1;
> ....
thanks.
--
~Randy
> On 5/3/20 12:23 AM, Dongyang Zhan wrote:
> > I am a security researcher, my name is Dongyang Zhan. I found a
> > potential bug.
Thank you for looking for bugs!
On 2020-05-03 Randy Dunlap wrote:
> On 5/3/20 12:23 AM, Dongyang Zhan wrote:
> > /lib/decompress_unxz.c forgets to free the pointer 'in', when the
> > statement if (fill == NULL && flush == NULL) is true.
>
> Adding xz contributor to email.
>
> I think that you are correct. (I am looking at 5.7-rc4.)
>
> However, I don't see any calls to __decompress() in the
> Linux kernel that pass a first argument of NULL, so while
> the code in unxz() could be fixed, we aren't currently leaking
> any memory AFAICT.
The supposedly leaked memory is allocated only when in == NULL, and
it's not freed when fill == NULL && flush == NULL. However, "in" and
"fill" must never be NULL at the same time if the caller is following
the decompress_fn API defined in include/linux/decompress/generic.h. So
there is no leak.
Some implementations of the API explicitly check for input == NULL &&
fill == NULL while some don't. E.g. decompress_unlz4.c checks it but in
addition it seems to also reject the case where input != NULL && fill
!= NULL. Perhaps that combination isn't used anywhere but it is allowed
by the API ("input" would be a temporary buffer for "fill"). I think
the decompress_fn API is more complex than it looks at glance.
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode