From: Cong Wang <xiyou.wangc...@gmail.com>
Date: Tue, 2 Jun 2020 21:49:10 -0700
> There are two kinds of memory leaks in genl_family_rcv_msg_dumpit():
>
> 1. Before we call ops->start(), whenever an error happens, we forget
> to free the memory allocated in genl_family_rcv_msg_dumpit().
>
> 2. When ops->start() fails, the 'info' has been already installed on
> the per socket control block, so we should not free it here. More
> importantly, nlk->cb_running is still false at this point, so
> netlink_sock_destruct() cannot free it either.
>
> The first kind of memory leaks is easier to resolve, but the second
> one requires some deeper thoughts.
>
> After reviewing how netfilter handles this, the most elegant solution
> I find is just to use a similar way to allocate the memory, that is,
> moving memory allocations from caller into ops->start(). With this,
> we can solve both kinds of memory leaks: for 1), no memory allocation
> happens before ops->start(); for 2), ops->start() handles its own
> failures and 'info' is installed to the socket control block only
> when success. The only ugliness here is we have to pass all local
> variables on stack via a struct, but this is not hard to understand.
>
> Alternatively, we can introduce a ops->free() to solve this too,
> but it is overkill as only genetlink has this problem so far.
>
> Fixes: 1927f41a22a0 ("net: genetlink: introduce dump info struct to be
> available during dumpit op")
> Reported-by: syzbot+21f04f481f449c8db...@syzkaller.appspotmail.com
> Cc: "Jason A. Donenfeld" <ja...@zx2c4.com>
> Cc: Florian Westphal <f...@strlen.de>
> Cc: Pablo Neira Ayuso <pa...@netfilter.org>
> Cc: Jiri Pirko <j...@mellanox.com>
> Cc: YueHaibing <yuehaib...@huawei.com>
> Cc: Shaochun Chen <cscn...@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
Applied and queued up for -stable, thanks.
