Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 29 Jul 2020 23:46:07 +0200
From:   Pablo Neira Ayuso <pablo@netfilter.org>
To:     Will McVicker <willmcvicker@google.com>
Cc:     security@kernel.org, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
        Florian Westphal <fw@strlen.de>,
        "David S. Miller" <davem@davemloft.net>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        kernel-team@android.com
Subject: Re: [PATCH 1/1] netfilter: nat: add range checks for access to
 nf_nat_l[34]protos[]
Message-ID: <20200729214607.GA30831@salvia>
References: <20200727175720.4022402-1-willmcvicker@google.com>
 <20200727175720.4022402-2-willmcvicker@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200727175720.4022402-2-willmcvicker@google.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Will,

On Mon, Jul 27, 2020 at 05:57:20PM +0000, Will McVicker wrote:
> The indexes to the nf_nat_l[34]protos arrays come from userspace. So we
> need to make sure that before indexing the arrays, we verify the index
> is within the array bounds in order to prevent an OOB memory access.
> Here is an example kernel panic on 4.14.180 when userspace passes in an
> index greater than NFPROTO_NUMPROTO.
> 
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:...
> Process poc (pid: 5614, stack limit = 0x00000000a3933121)
> CPU: 4 PID: 5614 Comm: poc Tainted: G S      W  O    4.14.180-g051355490483
> Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM
> task: 000000002a3dfffe task.stack: 00000000a3933121
> pc : __cfi_check_fail+0x1c/0x24
> lr : __cfi_check_fail+0x1c/0x24
> ...
> Call trace:
> __cfi_check_fail+0x1c/0x24
> name_to_dev_t+0x0/0x468
> nfnetlink_parse_nat_setup+0x234/0x258

If this oops is only triggerable from userspace, I think a sanity
check in nfnetlink_parse_nat_setup should suffice to reject
unsupported layer 3 and layer 4 protocols.

I mean, in this patch I see more chunks in the packet path, such as
nf_nat_l3proto_ipv4 that should never happen. I would just fix the
userspace ctnetlink path.

BTW, do you have a Fixes: tag for this? This will be useful for
-stable maintainer to pick up this fix.

Thanks.