[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAML_gOdZM8-mWXMbF7cHSo4X3zdNrytv_dTOrWvtnoxLzyP=XA@mail.gmail.com>
Date: Thu, 2 Mar 2017 19:18:17 +0800
From: Liping Zhang <zlpnobody@...il.com>
To: Gao Feng <fgao@...ai8.com>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
David Miller <davem@...emloft.net>,
Netfilter Developer Mailing List
<netfilter-devel@...r.kernel.org>, coreteam@...filter.org,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in
nat_rtp_rtcp and nf_nat_sdp_media
Hi,
2017-03-02 18:18 GMT+08:00 Gao Feng <fgao@...ai8.com>:
[...]
> The expect class is NF_CT_EXPECT_CLASS_DEFAULT, and proto is
> IPPROTO_UDP at the function "expect_rtp_rtcp",
> And it makes sure the port is even number.
>
> But look at the process_gcf, the port is got from the packet data at
> function get_h225_addr.
> So it may be odd number.
> It also would add one expect node whose class is
> NF_CT_EXPECT_CLASS_DEFAULT, and proto is IPPROTO_UDP.
The nat_rtp_rtcp() is only invoked by expect_rtp_rtcp, and nf_nat_sdp_media()
is only invoked by set_expected_rtp_rtcp. So the RTP port is ensured to be
even, as well as the rtp_exp->tuple.dst.u.udp.port.
Note: the rtp_exp is alloced by nf_ct_expect_alloc, and initialized by
nf_ct_expect_init, then passed to nat_rtp_rtcp or nf_nat_sdp_media.
So I cannot figure out why process_gcf will affect this? Or I missed something?
Powered by blists - more mailing lists