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
| ||
|
Date: Fri, 31 Jul 2020 00:26:11 +0000 From: William Mcvicker <willmcvicker@...gle.com> To: Pablo Neira Ayuso <pablo@...filter.org> Cc: security@...nel.org, Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>, Florian Westphal <fw@...len.de>, "David S. Miller" <davem@...emloft.net>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>, netfilter-devel@...r.kernel.org, coreteam@...filter.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...roid.com Subject: Re: [PATCH 1/1] netfilter: nat: add range checks for access to nf_nat_l[34]protos[] 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.
Powered by blists - more mailing lists