ACK: [PATCH 1/1] exec: Fix mem leak in kernel_read_file

[Colin Ian King]

On 05/03/2019 15:14, Tyler Hicks wrote:
> From: YueHaibing <yuehaibing at huawei.com>
> 
> syzkaller report this:
> BUG: memory leak
> unreferenced object 0xffffc9000488d000 (size 9195520):
>   comm "syz-executor.0", pid 2752, jiffies 4294787496 (age 18.757s)
>   hex dump (first 32 bytes):
>     ff ff ff ff ff ff ff ff a8 00 00 00 01 00 00 00  ................
>     02 00 00 00 00 00 00 00 80 a1 7a c1 ff ff ff ff  ..........z.....
>   backtrace:
>     [<000000000863775c>] __vmalloc_node mm/vmalloc.c:1795 [inline]
>     [<000000000863775c>] __vmalloc_node_flags mm/vmalloc.c:1809 [inline]
>     [<000000000863775c>] vmalloc+0x8c/0xb0 mm/vmalloc.c:1831
>     [<000000003f668111>] kernel_read_file+0x58f/0x7d0 fs/exec.c:924
>     [<000000002385813f>] kernel_read_file_from_fd+0x49/0x80 fs/exec.c:993
>     [<0000000011953ff1>] __do_sys_finit_module+0x13b/0x2a0 kernel/module.c:3895
>     [<000000006f58491f>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
>     [<00000000ee78baf4>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>     [<00000000241f889b>] 0xffffffffffffffff
> 
> It should goto 'out_free' lable to free allocated buf while kernel_read
> fails.
> 
> Fixes: 39d637af5aa7 ("vfs: forbid write access when reading a file into memory")
> Signed-off-by: YueHaibing <yuehaibing at huawei.com>
> Signed-off-by: Al Viro <viro at zeniv.linux.org.uk>
> 
> CVE-2019-8980
> 
> (cherry picked from commit f612acfae86af7ecad754ae6a46019be9da05b8e)
> Signed-off-by: Tyler Hicks <tyhicks at canonical.com>
> ---
>  fs/exec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index b9fd9abac832..d0099d6f434b 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -941,7 +941,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
>  		bytes = kernel_read(file, *buf + pos, i_size - pos, &pos);
>  		if (bytes < 0) {
>  			ret = bytes;
> -			goto out;
> +			goto out_free;
>  		}
>  
>  		if (bytes == 0)
> 

Acked-by: Colin Ian King <colin.king at canonical.com>