[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <353d9bad-5e94-5f7b-fa2a-689b0794b4a7@oracle.com>
Date: Fri, 3 Nov 2017 09:39:45 -0700
From: Girish Moodalbail <girish.moodalbail@...cle.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net 0/2] NULL pointer dereference in
{ipvlan|macvlan}_port_destroy
On 11/2/17 10:05 PM, David Miller wrote:
> From: Girish Moodalbail <girish.moodalbail@...cle.com>
> Date: Tue, 31 Oct 2017 09:39:45 -0700
>
>> When call to register_netdevice() (called from ipvlan_link_new())
>> fails, inside that function we call ipvlan_uninit() (through
>> ndo_uninit()) to destroy the ipvlan port. Upon returning
>> unsuccessfully from register_netdevice() we go ahead and call
>> ipvlan_port_destroy() again which causes NULL pointer dereference
>> panic.
>
> The problem is that ipvlan doesn't follow the proper convention that
> ->ndo_uninit() must only release resources allocated by ->ndo_init().
>
> What needs to happen is that the port allocation occur in
> ->ndo_init().
I agree, will send out V2. I initially started off making them (ndo_init and
ndo_uninit) symmetric by moving the port destruction out of ndo_uninit(), but I
hit some WARN() errors. Will figure it out.
thanks,
~Girish
>
> Your fix, while solving some cases, does not fully cover all of the
> posibiities due to this bug.
>
> Please fix this correctly by moving the port allocation and related
> setup from link creation to ->ndo_init().
>
> Thank you.
>
Powered by blists - more mailing lists