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

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:

@@ -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

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 ?!?

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 <[email protected]>             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

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.