netdev - Re: [Patch net v2] genetlink: fix memory leaks in genl_family_rcv_msg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 04 Jun 2020 15:36:53 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     xiyou.wangcong@...il.com
Cc:     netdev@...r.kernel.org,
        syzbot+21f04f481f449c8db840@...kaller.appspotmail.com,
        Jason@...c4.com, fw@...len.de, pablo@...filter.org,
        jiri@...lanox.com, yuehaibing@...wei.com, cscnull@...il.com
Subject: Re: [Patch net v2] genetlink: fix memory leaks in
 genl_family_rcv_msg_dumpit()

From: Cong Wang <xiyou.wangcong@...il.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+21f04f481f449c8db840@...kaller.appspotmail.com
> Cc: "Jason A. Donenfeld" <Jason@...c4.com>
> Cc: Florian Westphal <fw@...len.de>
> Cc: Pablo Neira Ayuso <pablo@...filter.org>
> Cc: Jiri Pirko <jiri@...lanox.com>
> Cc: YueHaibing <yuehaibing@...wei.com>
> Cc: Shaochun Chen <cscnull@...il.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>

Applied and queued up for -stable, thanks.