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.
