[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170816.141305.1998207836740801812.davem@davemloft.net>
Date: Wed, 16 Aug 2017 14:13:05 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: zlpnobody@....com
Cc: pshelar@....org, netdev@...r.kernel.org, zlpnobody@...il.com,
neil.mckee@...on.com
Subject: Re: [PATCH net V3] openvswitch: fix skb_panic due to the incorrect
actions attrlen
From: Liping Zhang <zlpnobody@....com>
Date: Wed, 16 Aug 2017 13:30:07 +0800
> From: Liping Zhang <zlpnobody@...il.com>
>
> For sw_flow_actions, the actions_len only represents the kernel part's
> size, and when we dump the actions to the userspace, we will do the
> convertions, so it's true size may become bigger than the actions_len.
>
> But unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len
> to alloc the skbuff, so the user_skb's size may become insufficient and
> oops will happen like this:
...
> Also we can find that the actions_len is much little than the orig_len:
> crash> struct sw_flow_actions 0xffff8812f539d000
> struct sw_flow_actions {
> rcu = {
> next = 0xffff8812f5398800,
> func = 0xffffe3b00035db32
> },
> orig_len = 1384,
> actions_len = 592,
> actions = 0xffff8812f539d01c
> }
>
> So as a quick fix, use the orig_len instead of the actions_len to alloc
> the user_skb.
>
> Last, this oops happened on our system running a relative old kernel, but
> the same risk still exists on the mainline, since we use the wrong
> actions_len from the beginning.
>
> Fixes: ccea74457bbd ("openvswitch: include datapath actions with sampled-packet upcall to userspace")
> Cc: Neil McKee <neil.mckee@...on.com>
> Signed-off-by: Liping Zhang <zlpnobody@...il.com>
Applied and queued up for -stable, thanks.
Powered by blists - more mailing lists