From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0BE0C43381 for ; Mon, 25 Feb 2019 09:35:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AC0632087C for ; Mon, 25 Feb 2019 09:35:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726614AbfBYJf2 (ORCPT ); Mon, 25 Feb 2019 04:35:28 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:4730 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726480AbfBYJf2 (ORCPT ); Mon, 25 Feb 2019 04:35:28 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id D15E1C327B8DE5A952B7; Mon, 25 Feb 2019 17:35:25 +0800 (CST) Received: from [127.0.0.1] (10.177.31.96) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.408.0; Mon, 25 Feb 2019 17:35:25 +0800 Subject: Re: [PATCH] xfrm: correctly check policy index in verify_newpolicy_info To: , , References: <20190225092704.26796-1-yuehaibing@huawei.com> CC: , From: YueHaibing Message-ID: <6ad236b2-53c2-54a4-4765-2b9746c49864@huawei.com> Date: Mon, 25 Feb 2019 17:35:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20190225092704.26796-1-yuehaibing@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.31.96] X-CFilter-Loop: Reflected Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Pls ignore this, sorry On 2019/2/25 17:27, Yue Haibing wrote: > From: YueHaibing > > UBSAN report this: > > UBSAN: Undefined behaviour in net/xfrm/xfrm_policy.c:1289:24 > index 6 is out of range for type 'unsigned int [6]' > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.162-514.55.6.9.x86_64+ #13 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 > 0000000000000000 1466cf39b41b23c9 ffff8801f6b07a58 ffffffff81cb35f4 > 0000000041b58ab3 ffffffff83230f9c ffffffff81cb34e0 ffff8801f6b07a80 > ffff8801f6b07a20 1466cf39b41b23c9 ffffffff851706e0 ffff8801f6b07ae8 > Call Trace: > [] __dump_stack lib/dump_stack.c:15 [inline] > [] dump_stack+0x114/0x1a0 lib/dump_stack.c:51 > [] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164 > [] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382 > [] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289 > [] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309 > [] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243 > [] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144 > [] __run_timers kernel/time/timer.c:1218 [inline] > [] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401 > [] __do_softirq+0x299/0xe10 kernel/softirq.c:273 > [] invoke_softirq kernel/softirq.c:350 [inline] > [] irq_exit+0x216/0x2c0 kernel/softirq.c:391 > [] exiting_irq arch/x86/include/asm/apic.h:652 [inline] > [] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926 > [] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735 > [] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52 > [] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline] > [] default_idle+0x27/0x430 arch/x86/kernel/process.c:446 > [] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437 > [] default_idle_call+0x53/0x90 kernel/sched/idle.c:92 > [] cpuidle_idle_call kernel/sched/idle.c:156 [inline] > [] cpu_idle_loop kernel/sched/idle.c:251 [inline] > [] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299 > [] start_secondary+0x3c9/0x560 arch/x86/kernel/smpboot.c:245 > > xfrm_add_policy calls verify_newpolicy_info to check user's policy info, > but it doest check policy index correcly, if the policy index(ex. 6) is great > than XFRM_POLICY_MAX which is 3 for now, the validation check will be bypassed. > It will trigger out of bounds access. > > Reported-by: Hulk Robot > Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user") > Signed-off-by: YueHaibing > --- > net/xfrm/xfrm_user.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c > index a131f9f..c2de950 100644 > --- a/net/xfrm/xfrm_user.c > +++ b/net/xfrm/xfrm_user.c > @@ -1424,7 +1424,8 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p) > ret = verify_policy_dir(p->dir); > if (ret) > return ret; > - if (p->index && ((p->index & XFRM_POLICY_MAX) != p->dir)) > + if (p->index && (p->index > XFRM_POLICY_MAX && > + (p->index & XFRM_POLICY_MAX) != p->dir)) > return -EINVAL; > > return 0; >