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  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, 12 May 2016 13:15:14 -0700
From:	Alexander Duyck <>
To:	Cong Wang <>
Cc:	Alexander Duyck <>,
	Linux Kernel Network Developers <>,
	David Miller <>,
	Thomas Graf <>, Tom Herbert <>,
	Jiri Benc <>,
	Eric Dumazet <>
Subject: Re: [net-next PATCH v2] udp: Resolve NULL pointer dereference over
 flow-based vxlan device

On Thu, May 12, 2016 at 1:02 PM, Cong Wang <> wrote:
> On Thu, May 12, 2016 at 12:51 PM, Alexander Duyck <> wrote:
>> The following trace is seen when receiving a DHCP request over a flow-based
>> VXLAN tunnel.  I believe this is caused by the metadata dst having a NULL
>> dev value and as a result dev_net(dev) is causing a NULL pointer dereference.
>> To resolve this I am replacing the check for skb_dst() with skb_valid_dst()
>> so that we do not attempt to use the metadata dst to retrieve a device in
>> order to determine the network namespace.
> Why does UDP layer need to care about tunnel layer things?
> If the problem is really what you describe, then the tunnel layer
> should reset that dst after finish.

A metadata dst is inserted by the tunnel layer after it has released
the regular dst that routed the packet to the tunnel.  My
understanding is it is used by OVS to handle the routing of the packet
after it has come out of the tunnel but before it has gone up through
the IP stack.  All of this was introduced back around the time of the
lightweight tunnels.

- Alex

Powered by blists - more mailing lists