At 2017-05-10 02:37:36, "David Miller" <da...@davemloft.net> wrote:
>From: gfree.w...@vip.163.com
>Date: Tue, 9 May 2017 18:27:33 +0800
>
>> @@ -989,6 +989,7 @@ static u32 vrf_fib_table(const struct net_device *dev)
>>
>> static int vrf_rcv_finish(struct net *net, struct sock *sk, struct sk_buff
>> *skb)
>> {
>> + kfree_skb(skb);
>> return 0;
>> }
>>
>> @@ -998,7 +999,7 @@ static struct sk_buff *vrf_rcv_nfhook(u8 pf, unsigned
>> int hook,
>> {
>> struct net *net = dev_net(dev);
>>
>> - if (NF_HOOK(pf, hook, net, NULL, skb, dev, NULL, vrf_rcv_finish) < 0)
>> + if (nf_hook(pf, hook, net, NULL, skb, dev, NULL, vrf_rcv_finish) != 1)
>> skb = NULL; /* kfree_skb(skb) handled by nf code */
>>
>> return skb;
>
>Indeed, this fixes the immediate problem with NF_STOLEN.
>
>Making NF_STOLEN fully functional is another story, we'd need to stack
>this all together properly:
Yes, this fix just make the vrf wouldn't cause panic which is caused by
use-after-free skb.
It doesn't work as real NF_QUEUE when reinject the skb.
>
>static int __ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff
>*skb)
>{
> ...
>}
>
>static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
>{
> return l3mdev_ip_rcv(skb, __ip_rcv_finish);
>}
>...
>static inline
>struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb,
> int (*okfn)(struct net *, struct sock *, struct
> sk_buff *))
>{
> return l3mdev_l3_rcv(skb, okfn, AF_INET);
>}
>
>etc. but that's going to really add a kink to the receive path,
>microbenchmark wise.
It is a solution to make NF_STOLEN fully function, but I haven't environment to
test the benchmark.
Best Regards
Feng
