Skip to contentSkip to conversation

mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()

PATCH Applied Eric Dumazet 5 participants 5 messages Oct 1, 2021 – Oct 8, 2021

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()

From: Eric Dumazet <[email protected]>

syzbot reported access to unitialized memory in mbind() [1]

Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")

This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in do_set_mempolicy()

This patch moves the check in sanitize_mpol_flags() so that it is also used by mbind()

[1]

BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
 mpol_equal include/linux/mempolicy.h:105 [inline]
 vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
 kernel_mbind mm/mempolicy.c:1483 [inline]
 __do_sys_mbind mm/mempolicy.c:1490 [inline]
 __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Uninit was created at:

 slab_alloc_node mm/slub.c:3221 [inline]
 slab_alloc mm/slub.c:3230 [inline]
 kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235
 mpol_new mm/mempolicy.c:293 [inline]
 do_mbind+0x912/0x15f0 mm/mempolicy.c:1289
 kernel_mbind mm/mempolicy.c:1483 [inline]
 __do_sys_mbind mm/mempolicy.c:1490 [inline]
 __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae
=====================================================
Kernel panic - not syncing: panic_on_kmsan set ...
CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G    B             5.15.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106
 dump_stack+0x25/0x28 lib/dump_stack.c:113
 panic+0x44f/0xdeb kernel/panic.c:232
 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186
 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208
 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
 mpol_equal include/linux/mempolicy.h:105 [inline]
 vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
 kernel_mbind mm/mempolicy.c:1483 [inline]
 __do_sys_mbind mm/mempolicy.c:1490 [inline]
 __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f4a41b2c709
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4a3f0a3188 EFLAGS: 00000246 ORIG_RAX: 00000000000000ed
RAX: ffffffffffffffda RBX: 00007f4a41c30f60 RCX: 00007f4a41b2c709
RDX: 0000000000002001 RSI: 0000000000c00007 RDI: 0000000020012000
RBP: 00007f4a41b86cb4 R08: 0000000000000000 R09: 0000010000000002
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4a42164b2f R14: 00007f4a3f0a3300 R15: 0000000000022000
Fixes bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")
Cc "Huang, Ying" <[email protected]>
Cc Mel Gorman <[email protected]>

---
v2: fix compiler warning reported by kernel test robot <[email protected]>

 mm/mempolicy.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)
mm/mempolicy.c +5 -11
index 1592b081c58ef6dd63c6f075ad24722f2be7cb5d..d12e0608fced235dc9137d0628437046299c7cfc 100644
@@ -856,16 +856,6 @@ static long do_set_mempolicy(unsigned short mode, unsigned short flags,
 		goto out;
 	}
 
-	if (flags & MPOL_F_NUMA_BALANCING) {
-		if (new && new->mode == MPOL_BIND) {
-			new->flags |= (MPOL_F_MOF | MPOL_F_MORON);
-		} else {
-			ret = -EINVAL;
-			mpol_put(new);
-			goto out;
-		}
-	}
-
 	ret = mpol_set_nodemask(new, nodes, scratch);
 	if (ret) {
 		mpol_put(new);
@@ -1458,7 +1448,11 @@ static inline int sanitize_mpol_flags(int *mode, unsigned short *flags)
 		return -EINVAL;
 	if ((*flags & MPOL_F_STATIC_NODES) && (*flags & MPOL_F_RELATIVE_NODES))
 		return -EINVAL;
-
+	if (*flags & MPOL_F_NUMA_BALANCING) {
+		if (*mode != MPOL_BIND)
+			return -EINVAL;
+		*flags |= (MPOL_F_MOF | MPOL_F_MORON);
+	}
 	return 0;
 }
 
Signature · 1 line
2.33.0.800.g4c38ced690-goog
maintainer
#1 lore raw
Quoted 3 lines · On Fri, 1 Oct 2021 14:56:30 -0700 Eric Dumazet <[email protected]> wrote:

From: Eric Dumazet <[email protected]>

syzbot reported access to unitialized memory in mbind() [1]

I'm lazy. What memory is being accessed-unintialized?

Quoted 2 lines

Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")

No cc:stable? What's the worst-case user-visible impact here?

#2 lore raw
Quoted 8 lines · Andrew Morton
Quoted 3 lines · On Fri, 1 Oct 2021 14:56:30 -0700 Eric Dumazet <[email protected]> wrote:

From: Eric Dumazet <[email protected]>

syzbot reported access to unitialized memory in mbind() [1]

I'm lazy. What memory is being accessed-unintialized?

I think you can clearly see that with this debug patch (courtesy of Alexander Potapenko) :
(Then issue various mbind( ...MPOL_F_NUMA_BALANCING | MPOL_LOCAL ...) in a loop... )

mm/mempolicy.c +0 -0
index 1592b081c58e..95a4d71efe99 100644
@@ -291,6 +291,7 @@ static struct mempolicy *mpol_new(unsigned short

mode, unsigned short flags,

        } else if (nodes_empty(*nodes))
                return ERR_PTR(-EINVAL);
        policy = kmem_cache_alloc(policy_cache, GFP_KERNEL);
+       memset(policy, 0xAA, sizeof(struct mempolicy));
        if (!policy)
                return ERR_PTR(-ENOMEM);
        atomic_set(&policy->refcnt, 1);
@@ -2256,9 +2257,12 @@ bool __mpol_equal(struct mempolicy *a, struct
mempolicy *b)
                return false;
        if (a->flags != b->flags)
                return false;

- if (mpol_store_user_nodemask(a))
+ if (mpol_store_user_nodemask(a)) {
+ pr_err("struct mempolicy *a: %px, nodemask: %px\n", a,
*(void**)&(a->w.user_nodemask));
+ pr_err("struct mempolicy *b: %px, nodemask: %px\n", b,

*(void**)&(b->w.user_nodemask));
                if (!nodes_equal(a->w.user_nodemask, b->w.user_nodemask))
                        return false;

+ }

        switch (a->mode) {
        case MPOL_BIND:
Quoted 5 lines
Quoted 3 lines

Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")

No cc:stable? What's the worst-case user-visible impact here?

I added the more precise tag : Fixes: bda420b98505 ("numa balancing:
migrate on fault among multiple bound nodes")
I only put Fixes: tag, so that stable teams can use their automation just fine.

worst-case impact, I am not sure if any application ever used this undocumented combinations of flags ?
Also, it is generally advised that accessing garbage values has undocumented behavior.
A host could for example crash (it certainly does with KMSAN)

#3 lore raw
Quoted 9 lines · Eric Dumazet
Quoted 4 lines
Quoted 2 lines

Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")

No cc:stable? What's the worst-case user-visible impact here?

I added the more precise tag : Fixes: bda420b98505 ("numa balancing:
migrate on fault among multiple bound nodes")
I only put Fixes: tag, so that stable teams can use their automation just fine.

Quoted 5 lines

worst-case impact, I am not sure if any application ever used this undocumented combinations of flags ?
Also, it is generally advised that accessing garbage values has undocumented behavior.
A host could for example crash (it certainly does with KMSAN)

mm has special stable rules; fixes only get backported if explicitly requested instead of automatically like most of the rest of the kernel.

#4 lore raw
In reply to Eric Dumazet

Hi, Eric,

Quoted 7 lines · Eric Dumazet

From: Eric Dumazet <[email protected]>

syzbot reported access to unitialized memory in mbind() [1]

Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes")

Quoted 6 lines

This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in do_set_mempolicy()

This patch moves the check in sanitize_mpol_flags() so that it is also used by mbind()

Good catch! Thanks! When MPOL_F_NUMA_BALANCING is introduced, it is intended to be used with set_memopolicy() syscall only, it is not allowed to be used with mbind() syscall at least for now. But I misunderstood the original code apparently.

So I think it may be better to return EINVAL for mbind() + MPOL_F_NUMA_BALANCING?

Best Regards,
Huang, Ying