netdev - Re: [PATCH v3 nf] netfilter: seqadj: Fix one possible panic in 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] [day] [month] [year] [list]

Date:   Mon, 5 Sep 2016 20:36:01 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     fgao@...ai8.com
Cc:     netfilter-devel@...r.kernel.org, fw@...len.de,
        coreteam@...filter.org, netdev@...r.kernel.org,
        gfree.wind@...il.com
Subject: Re: [PATCH v3 nf] netfilter: seqadj: Fix one possible panic in
 seqadj when mem is exhausted

On Sat, Sep 03, 2016 at 07:51:50PM +0800, fgao@...ai8.com wrote:
> From: Gao Feng <fgao@...ai8.com>
> 
> 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, while other functions perform the
> sanity check.
> 
> So the system would be panic when nfct_seqadj_ext_add failed.
> 
> Signed-off-by: Gao Feng <fgao@...ai8.com>
> ---
>  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_seqadj.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/net/netfilter/nf_conntrack_seqadj.c b/net/netfilter/nf_conntrack_seqadj.c
> index dff0f0c..7f8d814 100644
> --- a/net/netfilter/nf_conntrack_seqadj.c
> +++ b/net/netfilter/nf_conntrack_seqadj.c
> @@ -16,9 +16,12 @@ int nf_ct_seqadj_init(struct nf_conn *ct, enum ip_conntrack_info ctinfo,
>  	if (off == 0)
>  		return 0;
>  
> +	seqadj = nfct_seqadj(ct);
> +	if (unlikely(!seqadj))
> +		return 0;

I think we should handle this from init_conntrack() by simply dropping
the packet as we do under similar circunstances (too stress to deal).