CVE-2024-56592

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Call free_htab_elem() after htab_unlock_bucket()<br /> <br /> For htab of maps, when the map is removed from the htab, it may hold the<br /> last reference of the map. bpf_map_fd_put_ptr() will invoke<br /> bpf_map_free_id() to free the id of the removed map element. However,<br /> bpf_map_fd_put_ptr() is invoked while holding a bucket lock<br /> (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock<br /> (spinlock_t), triggering the following lockdep warning:<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.11.0-rc4+ #49 Not tainted<br /> -----------------------------<br /> test_maps/4881 is trying to lock:<br /> ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 2 locks held by test_maps/4881:<br /> #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270<br /> #1: ffff888149ced148 (&amp;htab-&gt;lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0xb0<br /> dump_stack+0x10/0x20<br /> __lock_acquire+0x73e/0x36c0<br /> lock_acquire+0x182/0x450<br /> _raw_spin_lock_irqsave+0x43/0x70<br /> bpf_map_free_id.part.0+0x21/0x70<br /> bpf_map_put+0xcf/0x110<br /> bpf_map_fd_put_ptr+0x9a/0xb0<br /> free_htab_elem+0x69/0xe0<br /> htab_map_update_elem+0x50f/0xa80<br /> bpf_fd_htab_map_update_elem+0x131/0x270<br /> htab_map_update_elem+0x50f/0xa80<br /> bpf_fd_htab_map_update_elem+0x131/0x270<br /> bpf_map_update_value+0x266/0x380<br /> __sys_bpf+0x21bb/0x36b0<br /> __x64_sys_bpf+0x45/0x60<br /> x64_sys_call+0x1b2a/0x20d0<br /> do_syscall_64+0x5d/0x100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> One way to fix the lockdep warning is using raw_spinlock_t for<br /> map_idr_lock as well. However, bpf_map_alloc_id() invokes<br /> idr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a<br /> similar lockdep warning because the slab&amp;#39;s lock (s-&gt;cpu_slab-&gt;lock) is<br /> still a spinlock.<br /> <br /> Instead of changing map_idr_lock&amp;#39;s type, fix the issue by invoking<br /> htab_put_fd_value() after htab_unlock_bucket(). However, only deferring<br /> the invocation of htab_put_fd_value() is not enough, because the old map<br /> pointers in htab of maps can not be saved during batched deletion.<br /> Therefore, also defer the invocation of free_htab_elem(), so these<br /> to-be-freed elements could be linked together similar to lru map.<br /> <br /> There are four callers for -&gt;map_fd_put_ptr:<br /> <br /> (1) alloc_htab_elem() (through htab_put_fd_value())<br /> It invokes -&gt;map_fd_put_ptr() under a raw_spinlock_t. The invocation of<br /> htab_put_fd_value() can not simply move after htab_unlock_bucket(),<br /> because the old element has already been stashed in htab-&gt;extra_elems.<br /> It may be reused immediately after htab_unlock_bucket() and the<br /> invocation of htab_put_fd_value() after htab_unlock_bucket() may release<br /> the newly-added element incorrectly. Therefore, saving the map pointer<br /> of the old element for htab of maps before unlocking the bucket and<br /> releasing the map_ptr after unlock. Beside the map pointer in the old<br /> element, should do the same thing for the special fields in the old<br /> element as well.<br /> <br /> (2) free_htab_elem() (through htab_put_fd_value())<br /> Its caller includes __htab_map_lookup_and_delete_elem(),<br /> htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().<br /> <br /> For htab_map_delete_elem(), simply invoke free_htab_elem() after<br /> htab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just<br /> like lru map, linking the to-be-freed element into node_to_free list<br /> and invoking free_htab_elem() for these element after unlock. It is safe<br /> to reuse batch_flink as the link for node_to_free, because these<br /> elements have been removed from the hash llist.<br /> <br /> Because htab of maps doesn&amp;#39;t support lookup_and_delete operation,<br /> __htab_map_lookup_and_delete_elem() doesn&amp;#39;t have the problem, so kept<br /> it as<br /> ---truncated---