netdev - Re: [PATCH 1/2 nf] netfilter: seqadj: Fix some possible panics of seqadj when mem is exhausted

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: <CAML_gOe+Ao5WEuVbTry_oekwsm2-ooZ074pgfpzxYzNehgLGjQ@mail.gmail.com>
Date:   Fri, 2 Sep 2016 12:50:48 +0800
From:   Liping Zhang <zlpnobody@...il.com>
To:     fgao@...ai8.com
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org, Feng Gao <gfree.wind@...il.com>
Subject: Re: [PATCH 1/2 nf] netfilter: seqadj: Fix some possible panics of
 seqadj when mem is exhausted

Hi Feng,
2016-09-02 9:48 GMT+08:00  <fgao@...ai8.com>:
> From: Gao Feng <fgao@...ai8.com>
> @@ -171,6 +176,11 @@ int nf_ct_seq_adjust(struct sk_buff *skb,
>         struct nf_ct_seqadj *this_way, *other_way;
>         int res;
>
> +       if (unlikely(!seqadj)) {

IPS_SEQ_ADJUST_BIT will be tested before we call nf_ct_seq_adjust(),
so I think seqadj
will never be NULL here.

> +               WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n");
> +               return 0;
> +       }
> +
>         this_way  = &seqadj->seq[dir];
>         other_way = &seqadj->seq[!dir];
>
> @@ -218,8 +228,10 @@ s32 nf_ct_seq_offset(const struct nf_conn *ct,
>         struct nf_conn_seqadj *seqadj = nfct_seqadj(ct);
>         struct nf_ct_seqadj *this_way;
>
> -       if (!seqadj)
> +       if (unlikely(!seqadj)) {
> +               WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n");

But in nf_ct_seq_offset, seqadj is likely to be NULL, see the function
call path:
tcp_packet->tcp_in_window->nf_ct_seq_offset, so WARN_ONCE seems unnecessary.

>                 return 0;
> +       }