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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimOzYG4Weh7wanYfU_qBM4tJDPz+zJZQx_H-vn0@mail.gmail.com>
Date:	Sat, 26 Mar 2011 21:36:15 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	Feng Gao <kernel.goter@...il.com>
Cc:	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>,
	Patrick McHardy <kaber@...sh.net>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH] ip_fragment:kernel may panic when replay big packet with
 RST flag

On Wed, Mar 23, 2011 at 6:49 PM, Feng Gao <kernel.goter@...il.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@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html