Re: [PATCH net 0/2] NULL pointer dereference in {ipvlan|macvlan}_port_destroy

[Girish Moodalbail]

On 11/2/17 10:05 PM, David Miller wrote:

From: Girish Moodalbail 
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.

Re: [PATCH net 0/2] NULL pointer dereference in {ipvlan|macvlan}_port_destroy

[David Miller]

From: Girish Moodalbail 
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().

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.

[PATCH net 0/2] NULL pointer dereference in {ipvlan|macvlan}_port_destroy

[Girish Moodalbail]

>From code inspection it appeared that there is a possibility where in
ipvlan_port_destroy() might be dealing with a port (struct ipvl_port)
that has already been destroyed and is therefore already NULL. However,
we don't check for NULL and continue to access the fields which results
in a kernel panic.

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.

To test this theory, I loaded up netdev-notifier-error-inject.ko and did 

# echo -22 > /sys/kernel/debug/notifier-error-inject/\
  netdev/actions/NETDEV_POST_INIT/error

# ip li add ipvl0 link enp7s0 type ipvlan

BUG: unable to handle kernel NULL pointer dereference at 0820
IP: ipvlan_port_destroy+0x2a/0xf0 [ipvlan]

Similar issue exists in macvlan_port_destroy(). The following two
patches fixes ipvlan and macvlan module.

-
Girish Moodalbail (2):
  ipvlan: NULL pointer dereference panic in ipvlan_port_destroy
  macvlan: NULL pointer dereference panic in macvlan_port_destroy

 drivers/net/ipvlan/ipvlan_main.c | 6 ++
 drivers/net/macvlan.c| 5 -
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
1.8.3.1