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 [thread overview]
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.
next prev parent reply other threads:[~2020-07-31 0:26 UTC|newest]
Thread overview: 20+ 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-27 19:07 ` [PATCH 0/1] Netfilter OOB memory access security patch Will McVicker
2020-07-27 19:07 ` Will McVicker
2020-08-20 8:23 ` Greg KH
2020-08-24 17:52 ` William Mcvicker
2020-07-27 19:07 ` [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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.