[PATCH] PPTP connection tracking: fixed oops during PPTP connect when interface under heavy load

[PATCH] PPTP connection tracking: fixed oops during PPTP connect when interface under heavy load

[Peter Zion]

Summary:

If PPTP connection tracking is running on a machine and certain PPTP
packets arrive out of order, or preceding packets never made
it to the machine, the PPTP connection tracking code will
dereference NULL pointers.  Reproduction steps are to attempt PPTP 
connections
to the machine on an interface under heavy load.

Reproduction:

1. Set up the vulnerable machine NATing a shared external connection to the
local network and with a PPTP daemon running that allows connections from
the external network.  It must have PPTP connection tracking enabled.

2. On a machine on the local network for which the vulnerable machine is
acting as a gateway to the external network, run hping2 about 8-15 times
simultaneously, until your ping response is around 500-800ms but with less
than 50% packet loss.  Use the following options: "hping2 -2 --destport 123
--keep -d 100 -i u1 <external address>", where <external address> is a 
machine
on the external network that won't mind being flooded for a few minutes.

3. On a machine on the external network, repeatedly make a PPTP
connection to the vulnerable machine.  In our experience the vulnerable
machine will oops about one in three PPTP connection attempts.

Patch:

--- linux.orig/net/ipv4/netfilter/ip_conntrack_proto_gre.c        Wed 
Nov 24 00:49:42 2004
+++ linux/net/ipv4/netfilter/ip_conntrack_proto_gre.c    Wed Nov 24 
00:46:15 2004
@@ -133,6 +133,13 @@ int ip_ct_gre_keymap_add(struct ip_connt
 void ip_ct_gre_keymap_change(struct ip_ct_gre_keymap *km,
                             struct ip_conntrack_tuple *t)
 {
+        if (!km)
+        {
+                printk(KERN_WARNING
+                        "NULL GRE conntrack keymap change requested\n");
+                return;
+        }
+
        DEBUGP("changing entry %p to: ", km);
        DUMP_TUPLE_GRE(t);
 
---
Peter Zion
Net Integration Technologies

Re: [PATCH] PPTP connection tracking: fixed oops during PPTP connect when interface under heavy load

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Thu, Jan 06, 2005 at 01:50:37PM -0500, Peter Zion wrote:
> Summary:
> 
> If PPTP connection tracking is running on a machine and certain PPTP
> packets arrive out of order, or preceding packets never made
> it to the machine, the PPTP connection tracking code will
> dereference NULL pointers.  Reproduction steps are to attempt PPTP 
> connections to the machine on an interface under heavy load.

That's really strange.  Can you please elaborate more?

The keymaps are added in ip_conntrack_pptp.c for OUT_CALL_REPLY and
IN_CALL_CONNECT messages.  And they are only changed by ip_nat_pptp.c
for exactly the same packets.

So if your bug report is correct, this means that packet arrive at
ip_nat_pptp.c but never go through ip_conntrack_pptp ?!?

> Patch:
> 
> [..]

I'd rather like to understand what's going on before applying your
patch.  And even if the soultion was similar, I would check for missing
keymaps at the caller rather than the callee.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] PPTP connection tracking: fixed oops during PPTP connect when interface under heavy load

[Peter Zion]

Harald Welte wrote:

>On Thu, Jan 06, 2005 at 01:50:37PM -0500, Peter Zion wrote:
>  
>
>>Summary:
>>
>>If PPTP connection tracking is running on a machine and certain PPTP
>>packets arrive out of order, or preceding packets never made
>>it to the machine, the PPTP connection tracking code will
>>dereference NULL pointers.  Reproduction steps are to attempt PPTP 
>>connections to the machine on an interface under heavy load.
>>    
>>
>
>That's really strange.  Can you please elaborate more?
>  
>
I'm afraid I can't: I don't pretend to understand exactly what the 
problem is.  In our case we were seeing random kernel oopses under heavy 
load, and once we managed to create the series of reproduction steps 
that I listed in the original email it was exactly the same NULL pointer 
dereference every time.  Simply checking the pointer before 
dereferencing it, as done in my patch, "fixed" the problem in the sense 
that the kernel no longer locks up, and we have not seen any further 
problems under heavy load since applying the patch.

The best I can offer you is help in isolating the problem.  If, for 
instance, you made a patch with debugging output that would help you 
isolate the problem, I would be happy to run it against our reproduction 
steps and tell you what happens.