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.
