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