On Mon, May 16, 2016 at 2:28 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Sun, May 15, 2016 at 12:06:46PM -0700, Cong Wang wrote:
>>
>> Similar to what Richard reported, I think the problem is cb->skb,
>> which is exposed to other thread since cb is per netlink socket
>> (cb = &nlk->cb). IOW, the cb->skb is freed by one thread at the
>> end of netlink_dump() meanwhile the other thread is still using
>> it via NETLINK_CB(cb->skb).portid.
>
> You're on the right track. I think what's happening is that the
> second thread is starting a new dump and the first thread ends up
> freeing the skb of the new dump and leaking the old skb.
>
> ---8<---
> Subject: netlink: Fix dump skb leak/double free
>
> When we free cb->skb after a dump, we do it after releasing the
> lock. This means that a new dump could have started in the time
> being and we'll end up freeing their skb instead of ours.
>
> This patch saves the skb and module before we unlock so we free
> the right memory.
Yeah, this fix makes more sense than mine.
>
> Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
> Reported-by: Baozeng Ding <splovi...@gmail.com>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Acked-by: Cong Wang <xiyou.wangc...@gmail.com>
Thanks.
