* [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
@ 2011-03-23 10:49 Feng Gao
2011-03-23 11:01 ` Eric Dumazet
2011-03-26 13:36 ` Changli Gao
0 siblings, 2 replies; 6+ messages in thread
From: Feng Gao @ 2011-03-23 10:49 UTC (permalink / raw)
To: netdev
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);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
2011-03-23 10:49 [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag Feng Gao
@ 2011-03-23 11:01 ` Eric Dumazet
2011-03-23 11:34 ` Feng Gao
2011-03-26 13:36 ` Changli Gao
1 sibling, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2011-03-23 11:01 UTC (permalink / raw)
To: Feng Gao; +Cc: netdev
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 ?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
2011-03-23 11:01 ` Eric Dumazet
@ 2011-03-23 11:34 ` Feng Gao
2011-03-23 11:37 ` Feng Gao
0 siblings, 1 reply; 6+ messages in thread
From: Feng Gao @ 2011-03-23 11:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
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 <eric.dumazet@gmail.com>:
> 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 ?
>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
2011-03-23 11:34 ` Feng Gao
@ 2011-03-23 11:37 ` Feng Gao
0 siblings, 0 replies; 6+ messages in thread
From: Feng Gao @ 2011-03-23 11:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
This patch is for 2.6.25.16.
2011/3/23 Feng Gao <kernel.goter@gmail.com>:
> 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 <eric.dumazet@gmail.com>:
>> 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 ?
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
2011-03-23 10:49 [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag Feng Gao
2011-03-23 11:01 ` Eric Dumazet
@ 2011-03-26 13:36 ` Changli Gao
2011-03-28 11:30 ` Patrick McHardy
1 sibling, 1 reply; 6+ messages in thread
From: Changli Gao @ 2011-03-26 13:36 UTC (permalink / raw)
To: Feng Gao
Cc: netdev, Eric Dumazet, Patrick McHardy,
Netfilter Developer Mailing List
On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao <kernel.goter@gmail.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag
2011-03-26 13:36 ` Changli Gao
@ 2011-03-28 11:30 ` Patrick McHardy
0 siblings, 0 replies; 6+ messages in thread
From: Patrick McHardy @ 2011-03-28 11:30 UTC (permalink / raw)
To: Changli Gao
Cc: Feng Gao, netdev, Eric Dumazet, Netfilter Developer Mailing List
On 26.03.2011 14:36, Changli Gao wrote:
> On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao <kernel.goter@gmail.com> 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.
That's correct, the skb's reference is refcounted seperately and
only dropped at the final kfree_skb().
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-28 11:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-23 10:49 [PATCH] ip_fragment:kernel may panic when replay big packet with RST flag Feng Gao
2011-03-23 11:01 ` Eric Dumazet
2011-03-23 11:34 ` Feng Gao
2011-03-23 11:37 ` Feng Gao
2011-03-26 13:36 ` Changli Gao
2011-03-28 11:30 ` Patrick McHardy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).