Re: [v2 PATCH 1/2] macvlan: Fix potential use-after free for broadcasts

2016-06-01 Thread Cong Wang
On Tue, May 31, 2016 at 9:27 PM, Herbert Xu wrote: > On Tue, May 31, 2016 at 09:19:37PM -0700, Cong Wang wrote: >> >> Hmm, why could this happen? The upper device should be linked >> with the lower device, where a refcount is already held. >> Also, the work is

Re: [v2 PATCH 1/2] macvlan: Fix potential use-after free for broadcasts

2016-05-31 Thread Herbert Xu
On Tue, May 31, 2016 at 09:19:37PM -0700, Cong Wang wrote: > > Hmm, why could this happen? The upper device should be linked > with the lower device, where a refcount is already held. > Also, the work is cancelled in ->uninit(). Of course it can happen. We are talking about the source macvlan

Re: [v2 PATCH 1/2] macvlan: Fix potential use-after free for broadcasts

2016-05-31 Thread Cong Wang
On Tue, May 31, 2016 at 8:43 PM, Herbert Xu wrote: > When we postpone a broadcast packet we save the source port in > the skb if it is local. However, the source port can disappear > before we get a chance to process the packet. > Hmm, why could this happen? The

[v2 PATCH 1/2] macvlan: Fix potential use-after free for broadcasts

2016-05-31 Thread Herbert Xu
When we postpone a broadcast packet we save the source port in the skb if it is local. However, the source port can disappear before we get a chance to process the packet. This patch fixes this by holding a ref count on the netdev. It also delays the skb->cb modification until after we allocate

[PATCH 1/2] macvlan: Fix potential use-after free for broadcasts

2016-05-30 Thread Herbert Xu
When we postpone a broadcast packet we save the source port in the skb if it is local. However, the source port can disappear before we get a chance to process the packet. This patch fixes this by holding a ref count on the netdev. It also delays the skb->cb modification until after we allocate