Netfilter-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: William Mcvicker <willmcvicker@google.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
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[]
Date: Fri, 31 Jul 2020 00:26:11 +0000
Message-ID: <20200731002611.GA1035680@google.com> (raw)
In-Reply-To: <20200729214607.GA30831@salvia>

Hi Pablo,

Yes, I believe this oops is only triggered by userspace when the user
specifically passes in an invalid nf_nat_l3protos index. I'm happy to re-work
the patch to check for this in ctnetlink_create_conntrack().

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

Regarding the Fixes: tag, I don't have one offhand since this bug was reported
to me, but I can search through the code history to find the commit that
exposed this vulnerability.

Thanks,
Will

On 07/29/2020, Pablo Neira Ayuso wrote:
> 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.

  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 17:57 [PATCH 0/1] Netfilter OOB memory access security patch Will McVicker
2020-07-27 17:57 ` [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[] Will McVicker
2020-07-29 21:46   ` Pablo Neira Ayuso
2020-07-31  0:26     ` William Mcvicker [this message]
2020-07-31 17:51       ` Pablo Neira Ayuso
2020-07-31 18:16         ` William Mcvicker
2020-08-03 18:31           ` [PATCH v2 1/1] netfilter: nat: add a range check for l3/l4 protonum William Mcvicker
2020-08-04 11:37             ` Pablo Neira Ayuso
2020-08-24 19:38               ` [PATCH v3 0/1] " Will McVicker
2020-08-24 19:38                 ` [PATCH v3 1/1] " Will McVicker
2020-08-28 16:42                   ` Pablo Neira Ayuso
2020-08-28 16:45                     ` Florian Westphal
2020-08-28 17:11                       ` Pablo Neira Ayuso
2020-09-01 15:36               ` [PATCH v2 " Will Deacon
2020-09-01 17:29                 ` William Mcvicker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200731002611.GA1035680@google.com \
    --to=willmcvicker@google.com \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=kernel-team@android.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=security@kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Netfilter-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netfilter-devel/0 netfilter-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netfilter-devel netfilter-devel/ https://lore.kernel.org/netfilter-devel \
		netfilter-devel@vger.kernel.org
	public-inbox-index netfilter-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netfilter-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git