[PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

STALE5643d

6 messages, 4 authors, 2011-03-28 · open the first message on its own page

[PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Feng Gao <hidden>
Date: 2011-03-23 10:49:11

Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
  if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
                /* If only reply is a RST, we can consider ourselves not to
                   have an established connection: this is a fairly common
                   problem case, so we can delete the conntrack
                   immediately.  --RR */
                if (th->rst) {
                        nf_ct_kill_acct(ct, ctinfo, skb);
                        return NF_ACCEPT;
                }
        }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.


here is the patch,sorry ,i dont know how to use diff to generate patch.
:-D

/* This func for ip_fragment deal with RST packet */
static inline void nf_copy_rst(struct sk_buff *dst, const struct sk_buff *src)
{
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
 nf_conntrack_put(dst->nfct);
 nf_conntrack_put_reasm(dst->nfct_reasm);
#endif
#ifdef CONFIG_BRIDGE_NETFILTER
 nf_bridge_put(dst->nf_bridge);
 dst->nf_bridge  = src->nf_bridge;
 nf_bridge_get(src->nf_bridge);
#endif
}

static void ip_copy_metadata(struct sk_buff *to, struct sk_buff *from)
{
 to->pkt_type = from->pkt_type;
 to->priority = from->priority;
 to->protocol = from->protocol;
 dst_release(to->dst);
 to->dst = dst_clone(from->dst);
 to->dev = from->dev;
 to->mark = from->mark;
 /* Copy the flags to each fragment. */
 IPCB(to)->flags = IPCB(from)->flags;
#ifdef CONFIG_NET_SCHED
 to->tc_index = from->tc_index;
#endif
 struct tcphdr *th = (struct tcphdr *)((char *)iph + (iph->ihl << 2));
 if(iph->protocol == IPPROTO_TCP && th->rst){
  /*RST packet*/
  nf_copy_rst(to, from);
 }else{
  /*Other packet*/
  nf_copy(to, from);
 }
#if defined(CONFIG_NETFILTER_XT_
TARGET_TRACE) || \
    defined(CONFIG_NETFILTER_XT_TARGET_TRACE_MODULE)
 to->nf_trace = from->nf_trace;
#endif
#if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
 to->ipvs_property = from->ipvs_property;
#endif
 skb_copy_secmark(to, from);
}

Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Eric Dumazet <hidden>
Date: 2011-03-23 11:02:00

Le mercredi 23 mars 2011 à 18:49 +0800, Feng Gao a écrit :
Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
  if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
                /* If only reply is a RST, we can consider ourselves not to
                   have an established connection: this is a fairly common
                   problem case, so we can delete the conntrack
                   immediately.  --RR */
                if (th->rst) {
                        nf_ct_kill_acct(ct, ctinfo, skb);
                        return NF_ACCEPT;
                }
        }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.


here is the patch,sorry ,i dont know how to use diff to generate patch.
:-D
Hi Feng

Oh well, please learn how to do this. If you are able to make such
analysis, you sure can learn how to use diff !!!

What is the version of linux you use ?


Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Feng Gao <hidden>
Date: 2011-03-23 11:34:32

Sorry, I will google it.
I find this problem in 2.4.35. and then I read the Latest code,maybe
it has the same problem too.

diff -Nur skbuff.h skbuff.h.frag
--- skbuff.h    2008-08-21 02:16:14.000000000 +0800
+++ skbuff.h.frag       2011-03-23 19:30:20.000000000 +0800
@@ -1754,6 +1754,20 @@
        __nf_copy(dst, src);
 }

+/* This func for ip_fragment deal with RST packet */
+static inline void nf_copy_rst(struct sk_buff *dst, const struct sk_buff *src)
+{
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+       nf_conntrack_put(dst->nfct);
+       nf_conntrack_put_reasm(dst->nfct_reasm);
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+       nf_bridge_put(dst->nf_bridge);
+       dst->nf_bridge  = src->nf_bridge;
+       nf_bridge_get(src->nf_bridge);
+#endif
+}
+
 #ifdef CONFIG_NETWORK_SECMARK
 static inline void skb_copy_secmark(struct sk_buff *to, const struct
sk_buff *from)
 {

diff -Nur ip_output.c ip_output.c.frag
--- ip_output.c 2008-08-21 02:16:14.000000000 +0800
+++ ip_output.c.frag    2011-03-23 19:27:57.000000000 +0800
@@ -413,7 +413,14 @@
 #ifdef CONFIG_NET_SCHED
        to->tc_index = from->tc_index;
 #endif
-       nf_copy(to, from);
+       struct tcphdr *th = (struct tcphdr *)((char *)iph + (iph->ihl << 2));
+       if(iph->protocol == IPPROTO_TCP && th->rst){
+               /*RST packet*/
+               nf_copy_rst(to, from);
+       }else{
+                /*Other packet*/
+               nf_copy(to, from);
+       }
 #if defined(CONFIG_NETFILTER_XT_TARGET_TRACE) || \
     defined(CONFIG_NETFILTER_XT_TARGET_TRACE_MODULE)
        to->nf_trace = from->nf_trace;
2011/3/23 Eric Dumazet [off-list ref]:
Le mercredi 23 mars 2011 à 18:49 +0800, Feng Gao a écrit :
quoted
Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
  if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
                /* If only reply is a RST, we can consider ourselves not to
                   have an established connection: this is a fairly common
                   problem case, so we can delete the conntrack
                   immediately.  --RR */
                if (th->rst) {
                        nf_ct_kill_acct(ct, ctinfo, skb);
                        return NF_ACCEPT;
                }
        }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.


here is the patch,sorry ,i dont know how to use diff to generate patch.
:-D
Hi Feng

Oh well, please learn how to do this. If you are able to make such
analysis, you sure can learn how to use diff !!!

What is the version of linux you use ?


Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Feng Gao <hidden>
Date: 2011-03-23 11:37:07

This patch is for 2.6.25.16.

2011/3/23 Feng Gao [off-list ref]:
quoted hunk
Sorry, I will google it.
I find this problem in 2.4.35. and then I read the Latest code,maybe
it has the same problem too.

diff -Nur skbuff.h skbuff.h.frag
--- skbuff.h    2008-08-21 02:16:14.000000000 +0800
+++ skbuff.h.frag       2011-03-23 19:30:20.000000000 +0800
@@ -1754,6 +1754,20 @@
       __nf_copy(dst, src);
 }

+/* This func for ip_fragment deal with RST packet */
+static inline void nf_copy_rst(struct sk_buff *dst, const struct sk_buff *src)
+{
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+       nf_conntrack_put(dst->nfct);
+       nf_conntrack_put_reasm(dst->nfct_reasm);
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+       nf_bridge_put(dst->nf_bridge);
+       dst->nf_bridge  = src->nf_bridge;
+       nf_bridge_get(src->nf_bridge);
+#endif
+}
+
 #ifdef CONFIG_NETWORK_SECMARK
 static inline void skb_copy_secmark(struct sk_buff *to, const struct
sk_buff *from)
 {

diff -Nur ip_output.c ip_output.c.frag
--- ip_output.c 2008-08-21 02:16:14.000000000 +0800
+++ ip_output.c.frag    2011-03-23 19:27:57.000000000 +0800
@@ -413,7 +413,14 @@
 #ifdef CONFIG_NET_SCHED
       to->tc_index = from->tc_index;
 #endif
-       nf_copy(to, from);
+       struct tcphdr *th = (struct tcphdr *)((char *)iph + (iph->ihl << 2));
+       if(iph->protocol == IPPROTO_TCP && th->rst){
+               /*RST packet*/
+               nf_copy_rst(to, from);
+       }else{
+                /*Other packet*/
+               nf_copy(to, from);
+       }
 #if defined(CONFIG_NETFILTER_XT_TARGET_TRACE) || \
    defined(CONFIG_NETFILTER_XT_TARGET_TRACE_MODULE)
       to->nf_trace = from->nf_trace;

2011/3/23 Eric Dumazet [off-list ref]:
quoted
Le mercredi 23 mars 2011 à 18:49 +0800, Feng Gao a écrit :
quoted
Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
  if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
                /* If only reply is a RST, we can consider ourselves not to
                   have an established connection: this is a fairly common
                   problem case, so we can delete the conntrack
                   immediately.  --RR */
                if (th->rst) {
                        nf_ct_kill_acct(ct, ctinfo, skb);
                        return NF_ACCEPT;
                }
        }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.


here is the patch,sorry ,i dont know how to use diff to generate patch.
:-D
Hi Feng

Oh well, please learn how to do this. If you are able to make such
analysis, you sure can learn how to use diff !!!

What is the version of linux you use ?


Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Changli Gao <hidden>
Date: 2011-03-26 13:36:15

On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao [off-list ref] wrote:
Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
 if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
               /* If only reply is a RST, we can consider ourselves not to
                  have an established connection: this is a fairly common
                  problem case, so we can delete the conntrack
                  immediately.  --RR */
               if (th->rst) {
                       nf_ct_kill_acct(ct, ctinfo, skb);
                       return NF_ACCEPT;
               }
       }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.
Have you ever tested that? I am afraid no panic will happen.
nf_ct_kill_acct() just drops the reference owned by the corresponding
timeout timer to the ct if the timer is installed, so the skb still
has the reference to the ct after nf_ct_kill_acct() returns. Thanks.

BTW: all the patches related to netfilter should be sent to the
netfilter developer mailing list.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag

From: Patrick McHardy <hidden>
Date: 2011-03-28 11:30:23

On 26.03.2011 14:36, Changli Gao wrote:
On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao [off-list ref] wrote:
quoted
Hello everyone:

PC(A)-linux(B)-PC(C)
computer(linux B) with two net interface,eth0 and eth1.
PC(A) send syn to PC(C)  though linux B.
then PC(C) replay a big packet  with RST flag(use tcpsic or other tools).

This RST packet(1480) come in from eth0(mtu 1500) and go out from
eth1(mtu 700), so this RST packet should fragment.

BUT in tcp_packet func: if the connection has no reply packet,and
receive the RST packet.ip_conntrack should  destroy.
 if (!test_bit(IPS_SEEN_REPLY_BIT, &ct->status)) {
               /* If only reply is a RST, we can consider ourselves not to
                  have an established connection: this is a fairly common
                  problem case, so we can delete the conntrack
                  immediately.  --RR */
               if (th->rst) {
                       nf_ct_kill_acct(ct, ctinfo, skb);
                       return NF_ACCEPT;
               }
       }

BUT the skb->nfct is not set NULL in func nf_ct_kill_acct.
so when this RST packet goto ip_fragment,ip_fragment call nf_copy, in
__nf_copy func
the fragment skb->nfct point to the destory mem.
dst->nfct = src->nfct;
nf_conntrack_get(src->nfct);

SO finally.kfree_skb call destroy_conntrack again. this may result in
LINUX B kernel panic.
Have you ever tested that? I am afraid no panic will happen.
nf_ct_kill_acct() just drops the reference owned by the corresponding
timeout timer to the ct if the timer is installed, so the skb still
has the reference to the ct after nf_ct_kill_acct() returns. Thanks.
That's correct, the skb's reference is refcounted seperately and
only dropped at the final kfree_skb().
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help