Re: [RFC PATCH] udp: don't rereference dst_entry dev pointer on rcv

David Miller
2013-03-07T23:15:30Z

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Mar 2013 14:47:24 -0800

> On Thu, 2013-03-07 at 22:36 +0000, Tom Parkin wrote:
>> When a fragmented IP packet is queued during device teardown, it is possible
>> for the reassembled packet to hit the UDP rcv path with a NULL dst_entry dev
>> pointer. Drop such packets to prevent an oops.
>> ---
>> net/ipv4/udp.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index 0a073a2..c38a4b1 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -1700,6 +1700,9 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
>> return __udp4_lib_mcast_deliver(net, skb, uh,
>> saddr, daddr, udptable);
>>
>> + if (skb_dst(skb)->dev == NULL)
>> + goto drop;
>> +
>> sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
>>
>> if (sk != NULL) {
>
>
> Hmm... couldnt it be tested in reassembly layer instead ?
>
> Why is it specific to UDP ?

Furthermore, when devices are unregistered we set the route's device
pointer to point to the loopback device, not NULL, exactly to avoid
this kind of problem.

I don't see anything in our generic DST handler nor the ipv4 specific
route handling, that would set dst->dev to NULL.

You really have to show us how this can actually happen.