diff mbox series

[v2] xfrm: correctly check policy index in verify_newpolicy_info

Message ID 20190225095600.26260-1-yuehaibing@huawei.com
State Awaiting Upstream
Delegated to: David Miller
Headers show
Series [v2] xfrm: correctly check policy index in verify_newpolicy_info | expand

Commit Message

Yue Haibing Feb. 25, 2019, 9:56 a.m. UTC 
From: YueHaibing <yuehaibing@huawei.com>

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:
 <IRQ>  [<ffffffff81cb35f4>] __dump_stack lib/dump_stack.c:15 [inline]
 <IRQ>  [<ffffffff81cb35f4>] dump_stack+0x114/0x1a0 lib/dump_stack.c:51
 [<ffffffff81d94225>] ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
 [<ffffffff81d954db>] __ubsan_handle_out_of_bounds+0x16e/0x1b2 lib/ubsan.c:382
 [<ffffffff82a25acd>] __xfrm_policy_unlink+0x3dd/0x5b0 net/xfrm/xfrm_policy.c:1289
 [<ffffffff82a2e572>] xfrm_policy_delete+0x52/0xb0 net/xfrm/xfrm_policy.c:1309
 [<ffffffff82a3319b>] xfrm_policy_timer+0x30b/0x590 net/xfrm/xfrm_policy.c:243
 [<ffffffff813d3927>] call_timer_fn+0x237/0x990 kernel/time/timer.c:1144
 [<ffffffff813d8e7e>] __run_timers kernel/time/timer.c:1218 [inline]
 [<ffffffff813d8e7e>] run_timer_softirq+0x6ce/0xb80 kernel/time/timer.c:1401
 [<ffffffff8120d6f9>] __do_softirq+0x299/0xe10 kernel/softirq.c:273
 [<ffffffff8120e676>] invoke_softirq kernel/softirq.c:350 [inline]
 [<ffffffff8120e676>] irq_exit+0x216/0x2c0 kernel/softirq.c:391
 [<ffffffff82c5edab>] exiting_irq arch/x86/include/asm/apic.h:652 [inline]
 [<ffffffff82c5edab>] smp_apic_timer_interrupt+0x8b/0xc0 arch/x86/kernel/apic/apic.c:926
 [<ffffffff82c5c985>] apic_timer_interrupt+0xa5/0xb0 arch/x86/entry/entry_64.S:735
 <EOI>  [<ffffffff81188096>] ? native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:52
 [<ffffffff810834d7>] arch_safe_halt arch/x86/include/asm/paravirt.h:111 [inline]
 [<ffffffff810834d7>] default_idle+0x27/0x430 arch/x86/kernel/process.c:446
 [<ffffffff81085f05>] arch_cpu_idle+0x15/0x20 arch/x86/kernel/process.c:437
 [<ffffffff8132abc3>] default_idle_call+0x53/0x90 kernel/sched/idle.c:92
 [<ffffffff8132b32d>] cpuidle_idle_call kernel/sched/idle.c:156 [inline]
 [<ffffffff8132b32d>] cpu_idle_loop kernel/sched/idle.c:251 [inline]
 [<ffffffff8132b32d>] cpu_startup_entry+0x60d/0x9a0 kernel/sched/idle.c:299
 [<ffffffff8113e119>] 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 does not check policy index correcly, if the policy index(ex. 6) is great
than or equal to the twice of XFRM_POLICY_MAX (XFRM_POLICY_MAX = 3), it may pass
the check. Then __xfrm_policy_unlink use the index to access array policy_count
whose size is XFRM_POLICY_MAX * 2, triggering out of bounds access.

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: e682adf021be ("xfrm: Try to honor policy index if it's supplied by user")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: respin the patch
---
 net/xfrm/xfrm_user.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Herbert Xu Feb. 25, 2019, 1:43 p.m. UTC | #1 
On Mon, Feb 25, 2019 at 05:56:00PM +0800, Yue Haibing wrote:
>
> the check. Then __xfrm_policy_unlink use the index to access array policy_count
> whose size is XFRM_POLICY_MAX * 2, triggering out of bounds access.

No it doesn't.  Even if it did the bug would be in __xfrm_policy_unlink
and not here.

Your patch makes no sense.

Cheers,
Yue Haibing Feb. 27, 2019, 3:17 a.m. UTC | #2 
On 2019/2/25 21:43, Herbert Xu wrote:
> On Mon, Feb 25, 2019 at 05:56:00PM +0800, Yue Haibing wrote:
>>
>> the check. Then __xfrm_policy_unlink use the index to access array policy_count
>> whose size is XFRM_POLICY_MAX * 2, triggering out of bounds access.
> 
> No it doesn't.  Even if it did the bug would be in __xfrm_policy_unlink
> and not here.
> 

Yes, my fix is wrong.

The issue is triggered as this:

xfrm_add_policy
    -->verify_newpolicy_info  //here check the index provided by user with XFRM_POLICY_MAX
			      //In my case, the index is 0x6E6BB6, so it pass the check.
    -->xfrm_policy_construct  //copy the user's policy and set xfrm_policy_timer
    -->xfrm_policy_insert
	--> __xfrm_policy_link //use the orgin dir, in my case is 2
	--> xfrm_gen_index   //generate policy index, there is 0x6E6BB6

then xfrm_policy_timer be fired

xfrm_policy_timer
   --> xfrm_policy_id2dir  //get dir from policy index & 7, in my case is 6
   --> xfrm_policy_delete
      --> __xfrm_policy_unlink //There access policy_count[dir], it trigger out of range access

So maybe the fix is like this:

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 8d1a898..b27eb742 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -316,6 +316,8 @@ static void xfrm_policy_timer(struct timer_list *t)
                goto out;

        dir = xfrm_policy_id2dir(xp->index);
+       if (dir >= XFRM_POLICY_MAX * 2)
+               dir = dir & XFRM_POLICY_MAX;

        if (xp->lft.hard_add_expires_seconds) {
                time64_t tmo = xp->lft.hard_add_expires_seconds +



> Your patch makes no sense.
> 
> Cheers,
>
diff mbox series

Patch

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a131f9f..60adacf 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 * 2) ||
+			 (p->index & XFRM_POLICY_MAX) != p->dir))
 		return -EINVAL;
 
 	return 0;