Hi Pablo,
On Tue, Sep 6, 2016 at 10:54 PM, Gao Feng <fgao@xxxxxxxxxx> wrote:
> inline
>
> On Tue, Sep 6, 2016 at 10:51 PM, Florian Westphal <fw@xxxxxxxxx> wrote:
>> fgao@xxxxxxxxxx <fgao@xxxxxxxxxx> wrote:
>>> From: Gao Feng <fgao@xxxxxxxxxx>
>>>
>>> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
>>> extension. But the function nf_ct_seqadj_init doesn't check if get valid
>>> seqadj pointer by the nfct_seqadj.
>>>
>>> Now drop the packet directly when fail to add seqadj extension to avoid
>>> dereference NULL pointer in nf_ct_seqadj_init.
>>>
>>> Signed-off-by: Gao Feng <fgao@xxxxxxxxxx>
>>> ---
>>> v5: Return NF_ACCEPT instead of NF_DROP when nfct_seqadj_ext_add failed in nf_nat_setup_info
>>> v4: Drop the packet directly when fail to add seqadj extension;
>>> v3: Remove the warning log when seqadj is null;
>>> v2: Remove the unnessary seqadj check in nf_ct_seq_adjust
>>> v1: Initial patch
>>>
>>> net/netfilter/nf_conntrack_core.c | 6 +++++-
>>> net/netfilter/nf_nat_core.c | 3 ++-
>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
>>> index dd2c43a..dfa76ce 100644
>>> --- a/net/netfilter/nf_conntrack_core.c
>>> +++ b/net/netfilter/nf_conntrack_core.c
>>> @@ -1036,7 +1036,11 @@ init_conntrack(struct net *net, struct nf_conn *tmpl,
>>> return (struct nf_conntrack_tuple_hash *)ct;
>>>
>>> if (tmpl && nfct_synproxy(tmpl)) {
>>> - nfct_seqadj_ext_add(ct);
>>> + if (!nfct_seqadj_ext_add(ct)) {
>>> + nf_conntrack_free(ct);
>>> + pr_debug("Can't add seqadj extension\n");
>>> + return NULL;
>>> + }
>>
>> if (!nfct_add_synrpxy(ct, tmpl)) {
>> nf_conntrack_free(ct);
>> return NULL;
>> }
>>
>> static bool nf_ct_add_synproxy(struct nf_conn *ct, const struct nf_conn *tmpl)
>> {
>> if (tmpl && nfct_synproxy(tmpl)) {
>> if (!nfct_seqadj_ext_add(ct))
>> return false;
>>
>> if (!nfct_synproxy_ext_add(ct))
>> return false;
>> }
>>
>> return true;
>> }
>>
>>> diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
>>> index de31818..f8b916a 100644
>>> --- a/net/netfilter/nf_nat_core.c
>>> +++ b/net/netfilter/nf_nat_core.c
>>> @@ -441,7 +441,8 @@ nf_nat_setup_info(struct nf_conn *ct,
>>> ct->status |= IPS_DST_NAT;
>>>
>>> if (nfct_help(ct))
>>> - nfct_seqadj_ext_add(ct);
>>> + if (!nfct_seqadj_ext_add(ct))
>>> + return NF_ACCEPT;
>>> }
>>
>> Hmm, why accept?
>>
>> We are asked to add extension to rewrite sequence numbers, but
>> we cannot. How can the connection work if we cannot munge/track
>> seqno rewrites?
>
> I thought we should drop the packet in that case before.
> But Pablo point out one case that the ctnetlink also could add the
> seqadj extension too.
> There is one synchronization case.
>
> I think he is right. Then modify the patch according to his advice.
>
> Best Regards
> Feng
I find the commit which uses seqadj extension firstly in ctnetlink.
But I think it should be ok and reply the details in my "v4" patch of
this subject.
Could you check it please?
If my understanding is wrong, I could send one patch to fix it.
Regards
Feng
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
