In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/slab: do not wake up kswapd in __kfree_rcu_sheaf()<\/p>\n
Since kfree_rcu() can be called under pi_lock (a raw spinlock in the
\nscheduler), kfree_rcu() itself should never allocate memory with
\n__GFP_KSWAPD_RECLAIM as waking up kswapd ends up acquiring pi_lock,
\nwhich leads to a deadlock.<\/p>\n
Reproducing the issue even intentionally was not straightforward.
\nThe set_cpus_allowed_force() path that is called under pi_lock is
\nexercised very rarely, and competing tasks that allocate memory will
\nmost likely wake kswapd up.<\/p>\n
Therefore the existence of the deadlock was verified with a modified
\nkernel that has a lockdep map for waking up kswapd:<\/p>\n
======================================================
\n WARNING: possible circular locking dependency detected
\n 7.2.0-rc1-slab-for-next+ #10 Not tainted
\n ——————————————————
\n git\/6660 is trying to acquire lock:
\n ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12\/0x20<\/p>\n
but task is already holding lock:
\n ffff8e57bffff1a0 (&pgdat->kswapd_wait){….}-{3:3}, at: _raw_spin_lock_irqsave+0x12\/0x20<\/p>\n
which lock already depends on the new lock.<\/p>\n
the existing dependency chain (in reverse order) is:<\/p>\n
-> #2 (&pgdat->kswapd_wait){….}-{3:3}:
\n __lock_acquire+0x5a4\/0xc50
\n lock_acquire.part.0+0xb7\/0x240
\n lock_acquire+0x70\/0x170
\n __raw_spin_lock_irqsave+0x44\/0x80
\n _raw_spin_lock_irqsave+0x12\/0x20
\n __wake_up_common_lock+0x31\/0xa0
\n __wake_up+0x20\/0x40
\n kswapd_wakeup_wake+0x7e\/0x110
\n wakeup_kswapd+0x295\/0x320
\n wake_all_kswapds+0xac\/0x1a0
\n __alloc_pages_slowpath.constprop.0+0x282\/0xf80
\n __alloc_frozen_pages_noprof+0x32a\/0x360
\n alloc_slab_page+0x2e\/0x160
\n allocate_slab+0x82\/0x420
\n new_slab+0x52\/0xb0
\n refill_objects+0x13d\/0x190
\n refill_sheaf+0x5d\/0xd0
\n __pcs_replace_empty_main+0x230\/0xb10
\n […]<\/p>\n
-> #1 (kswapd_wakeup){-.-.}-{0:0}:
\n __lock_acquire+0x5a4\/0xc50
\n lock_sync.part.0+0x75\/0x100
\n lock_sync+0x36\/0x70
\n might_wakeup_kswapd+0x61\/0xa0
\n __kfree_rcu_sheaf+0x33\/0xd90
\n kvfree_call_rcu+0x1d4\/0x3b0
\n set_cpus_allowed_force+0x163\/0x220
\n cpuset_cpus_allowed_fallback+0x18b\/0x240
\n select_fallback_rq+0x1e6\/0x250
\n\t […]<\/p>\n
-> #0 (&p->pi_lock){-.-.}-{2:2}:
\n check_prev_add+0xe6\/0xe00
\n validate_chain+0x51e\/0x6e0
\n __lock_acquire+0x5a4\/0xc50
\n lock_acquire.part.0+0xb7\/0x240
\n lock_acquire+0x70\/0x170
\n __raw_spin_lock_irqsave+0x44\/0x80
\n _raw_spin_lock_irqsave+0x12\/0x20
\n try_to_wake_up+0x77\/0xa90
\n default_wake_function+0x27\/0x60
\n autoremove_wake_function+0x23\/0xb0
\n __wake_up_common+0xb8\/0x170
\n __wake_up_common_lock+0x51\/0xa0
\n __wake_up+0x20\/0x40
\n kswapd_wakeup_wake+0x7e\/0x110
\n wakeup_kswapd+0x295\/0x320
\n wake_all_kswapds+0xac\/0x1a0
\n __alloc_pages_slowpath.constprop.0+0x282\/0xf80
\n __alloc_frozen_pages_noprof+0x32a\/0x360
\n alloc_slab_page+0x2e\/0x160
\n allocate_slab+0x82\/0x420
\n new_slab+0x52\/0xb0
\n refill_objects+0x13d\/0x190
\n refill_sheaf+0x5d\/0xd0
\n __pcs_replace_empty_main+0x230\/0xb10
\n […]<\/p>\n
other info that might help us debug this:<\/p>\n
Chain exists of:
\n &p->pi_lock –> kswapd_wakeup –> &pgdat->kswapd_wait<\/p>\n
Possible unsafe locking scenario:<\/p>\n
CPU0 CPU1
\n —- —-
\n lock(&pgdat->kswapd_wait);
\n lock(kswapd_wakeup);
\n lock(&pgdat->kswapd_wait);
\n lock(&p->pi_lock);<\/p>\n
*** DEADLOCK ***<\/p>\n
3 locks held by git\/6660:
\n #0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d\/0x60
\n #1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/slab: do not wake up kswapd in __kfree_rcu_sheaf()<\/p>\n
Since kfree_rcu() can be called under pi_lock (a raw spinlock in the
\nschedul<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-41290","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/41290","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=41290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}