[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1510902977-7931-1-git-send-email-girish.moodalbail@oracle.com>
Date: Thu, 16 Nov 2017 23:16:16 -0800
From: Girish Moodalbail <girish.moodalbail@...cle.com>
To: netdev@...r.kernel.org, davem@...emloft.net, mahesh@...dewar.net
Subject: [PATCH net v2 0/1] NULL pointer dereference in ipvlan_port_destroy
>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
$ sudo echo -22 > /sys/kernel/debug/notifier-error-inject/\
netdev/actions/NETDEV_POST_INIT/error
$ sudo ip li add ipvl0 link enp7s0 type ipvlan
...system panics...
BUG: unable to handle kernel NULL pointer dereference at 0000000000000820
IP: ipvlan_port_destroy+0x2a/0xf0 [ipvlan]
Similar issue exists in macvlan_port_destroy() and it will be addressed
by a separate patch. The following patch fixes the ipvlan case. I tested
my changes for regression by running LTP's ipvlan test case.
Girish Moodalbail (1):
ipvlan: NULL pointer dereference panic in ipvlan_port_destroy
drivers/net/ipvlan/ipvlan_main.c | 104 +++++++++++++++++++++------------------
1 file changed, 55 insertions(+), 49 deletions(-)
--
1.8.3.1
Powered by blists - more mailing lists