Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: add a schedule point in io_add_buffers()<br /> <br /> Looping ~65535 times doing kmalloc() calls can trigger soft lockups,<br /> especially with DEBUG features (like KASAN).<br /> <br /> [ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]<br /> [ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)<br /> [ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801<br /> [ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)<br /> [ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40<br /> [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246<br /> [ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001<br /> [ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a<br /> [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004<br /> [ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380<br /> [ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0<br /> [ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000<br /> [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0<br /> [ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 253.544494] Call Trace:<br /> [ 253.544496] <br /> [ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544505] __kernel_text_address (kernel/extable.c:78)<br /> [ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)<br /> [ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)<br /> [ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544521] stack_trace_save (kernel/stacktrace.c:123)<br /> [ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)<br /> [ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)<br /> [ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)<br /> [ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)<br /> [ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?)<br /> [ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524)<br /> [ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)<br /> [ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)<br /> [ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)<br /> [ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)<br /> [ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)<br /> [ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441)<br /> [ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)<br /> [ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)<br /> [ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> [ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)<br /> [ 253.544596] __io_queue_sqe (fs/io_uring.c:?)<br /> [ 253.544600] io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544603] io_submit_sqe (fs/io_uring.c:?)<br /> [ 253.544608] io_submit_sqes (fs/io_uring.c:?)<br /> [ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> CDC-NCM: avoid overflow in sanity checking<br /> <br /> A broken device may give an extreme offset like 0xFFF0<br /> and a reasonable length for a fragment. In the sanity<br /> check as formulated now, this will create an integer<br /> overflow, defeating the sanity check. Both offset<br /> and offset + len need to be checked in such a manner<br /> that no overflow can occur.<br /> And those quantities should be unsigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add schedule points in batch ops<br /> <br /> syzbot reported various soft lockups caused by bpf batch operations.<br /> <br /> INFO: task kworker/1:1:27 blocked for more than 140 seconds.<br /> INFO: task hung in rcu_barrier<br /> <br /> Nothing prevents batch ops to process huge amount of data,<br /> we need to add schedule points in them.<br /> <br /> Note that maybe_wait_bpf_programs(map) calls from<br /> generic_map_delete_batch() can be factorized by moving<br /> the call after the loop.<br /> <br /> This will be done later in -next tree once we get this fix merged,<br /> unless there is strong opinion doing this optimization sooner.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix crash due to incorrect copy_map_value<br /> <br /> When both bpf_spin_lock and bpf_timer are present in a BPF map value,<br /> copy_map_value needs to skirt both objects when copying a value into and<br /> out of the map. However, the current code does not set both s_off and<br /> t_off in copy_map_value, which leads to a crash when e.g. bpf_spin_lock<br /> is placed in map value with bpf_timer, as bpf_map_update_elem call will<br /> be able to overwrite the other timer object.<br /> <br /> When the issue is not fixed, an overwriting can produce the following<br /> splat:<br /> <br /> [root@(none) bpf]# ./test_progs -t timer_crash<br /> [ 15.930339] bpf_testmod: loading out-of-tree module taints kernel.<br /> [ 16.037849] ==================================================================<br /> [ 16.038458] BUG: KASAN: user-memory-access in __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.038944] Write of size 8 at addr 0000000000043ec0 by task test_progs/325<br /> [ 16.039399]<br /> [ 16.039514] CPU: 0 PID: 325 Comm: test_progs Tainted: G OE 5.16.0+ #278<br /> [ 16.039983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014<br /> [ 16.040485] Call Trace:<br /> [ 16.040645] <br /> [ 16.040805] dump_stack_lvl+0x59/0x73<br /> [ 16.041069] ? __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.041427] kasan_report.cold+0x116/0x11b<br /> [ 16.041673] ? __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.042040] __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.042328] ? memcpy+0x39/0x60<br /> [ 16.042552] ? pv_hash+0xd0/0xd0<br /> [ 16.042785] ? lockdep_hardirqs_off+0x95/0xd0<br /> [ 16.043079] __bpf_spin_lock_irqsave+0xdf/0xf0<br /> [ 16.043366] ? bpf_get_current_comm+0x50/0x50<br /> [ 16.043608] ? jhash+0x11a/0x270<br /> [ 16.043848] bpf_timer_cancel+0x34/0xe0<br /> [ 16.044119] bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81<br /> [ 16.044500] bpf_trampoline_6442477838_0+0x36/0x1000<br /> [ 16.044836] __x64_sys_nanosleep+0x5/0x140<br /> [ 16.045119] do_syscall_64+0x59/0x80<br /> [ 16.045377] ? lock_is_held_type+0xe4/0x140<br /> [ 16.045670] ? irqentry_exit_to_user_mode+0xa/0x40<br /> [ 16.046001] ? mark_held_locks+0x24/0x90<br /> [ 16.046287] ? asm_exc_page_fault+0x1e/0x30<br /> [ 16.046569] ? asm_exc_page_fault+0x8/0x30<br /> [ 16.046851] ? lockdep_hardirqs_on+0x7e/0x100<br /> [ 16.047137] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 16.047405] RIP: 0033:0x7f9e4831718d<br /> [ 16.047602] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48<br /> [ 16.048764] RSP: 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023<br /> [ 16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d<br /> [ 16.049747] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0<br /> [ 16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0<br /> [ 16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30<br /> [ 16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 16.051608] <br /> [ 16.051762] ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix concurrent reset and removal of VFs<br /> <br /> Commit c503e63200c6 ("ice: Stop processing VF messages during teardown")<br /> introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is<br /> intended to prevent some issues with concurrently handling messages from<br /> VFs while tearing down the VFs.<br /> <br /> This change was motivated by crashes caused while tearing down and<br /> bringing up VFs in rapid succession.<br /> <br /> It turns out that the fix actually introduces issues with the VF driver<br /> caused because the PF no longer responds to any messages sent by the VF<br /> during its .remove routine. This results in the VF potentially removing<br /> its DMA memory before the PF has shut down the device queues.<br /> <br /> Additionally, the fix doesn&amp;#39;t actually resolve concurrency issues within<br /> the ice driver. It is possible for a VF to initiate a reset just prior<br /> to the ice driver removing VFs. This can result in the remove task<br /> concurrently operating while the VF is being reset. This results in<br /> similar memory corruption and panics purportedly fixed by that commit.<br /> <br /> Fix this concurrency at its root by protecting both the reset and<br /> removal flows using the existing VF cfg_lock. This ensures that we<br /> cannot remove the VF while any outstanding critical tasks such as a<br /> virtchnl message or a reset are occurring.<br /> <br /> This locking change also fixes the root cause originally fixed by commit<br /> c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we<br /> can simply revert it.<br /> <br /> Note that I kept these two changes together because simply reverting the<br /> original commit alone would leave the driver vulnerable to worse race<br /> conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> configfs: fix a race in configfs_{,un}register_subsystem()<br /> <br /> When configfs_register_subsystem() or configfs_unregister_subsystem()<br /> is executing link_group() or unlink_group(),<br /> it is possible that two processes add or delete list concurrently.<br /> Some unfortunate interleavings of them can cause kernel panic.<br /> <br /> One of cases is:<br /> A --&gt; B --&gt; C --&gt; D<br /> A next = next |<br /> | // prev == B<br /> | prev-&gt;next = next<br /> <br /> Fix this by adding mutex when calling link_group() or unlink_group(),<br /> but parent configfs_subsystem is NULL when config_item is root.<br /> So I create a mutex configfs_subsystem_mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte<br /> <br /> When adding a rule with 32 destinations, we hit the following out-of-band<br /> access issue:<br /> <br /> BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70<br /> <br /> This patch fixes the issue by both increasing the allocated buffers to<br /> accommodate for the needed actions and by checking the number of actions<br /> to prevent this issue when a rule with too many actions is provided.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix memory leak during stateful obj update<br /> <br /> stateful objects can be updated from the control plane.<br /> The transaction logic allocates a temporary object for this purpose.<br /> <br /> The -&gt;init function was called for this object, so plain kfree() leaks<br /> resources. We must call -&gt;destroy function of the object.<br /> <br /> nft_obj_destroy does this, but it also decrements the module refcount,<br /> but the update path doesn&amp;#39;t increment it.<br /> <br /> To avoid special-casing the update object release, do module_get for<br /> the update case too and release it via nft_obj_destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()<br /> <br /> ida_simple_get() returns an id between min (0) and max (NFP_MAX_MAC_INDEX)<br /> inclusive.<br /> So NFP_MAX_MAC_INDEX (0xff) is a valid id.<br /> <br /> In order for the error handling path to work correctly, the &amp;#39;invalid&amp;#39;<br /> value for &amp;#39;ida_idx&amp;#39; should not be in the 0..NFP_MAX_MAC_INDEX range,<br /> inclusive.<br /> <br /> So set it to -1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: unregister flowtable hooks on netns exit<br /> <br /> Unregister flowtable hooks before they are releases via<br /> nf_tables_flowtable_destroy() otherwise hook core reports UAF.<br /> <br /> BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142<br /> Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666<br /> <br /> CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106<br /> dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106<br /> print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247<br /> __kasan_report mm/kasan/report.c:433 [inline]<br /> __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450<br /> kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450<br /> nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142<br /> __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429<br /> nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571<br /> nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232<br /> nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430<br /> nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]<br /> nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]<br /> nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652<br /> nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652<br /> nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652<br /> <br /> __nft_release_hook() calls nft_unregister_flowtable_net_hooks() which<br /> only unregisters the hooks, then after RCU grace period, it is<br /> guaranteed that no packets add new entries to the flowtable (no flow<br /> offload rules and flowtable hooks are reachable from packet path), so it<br /> is safe to call nf_flow_table_free() which cleans up the remaining<br /> entries from the flowtable (both software and hardware) and it unbinds<br /> the flow_block.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: rndis: add spinlock for rndis response list<br /> <br /> There&amp;#39;s no lock for rndis response list. It could cause list corruption<br /> if there&amp;#39;re two different list_add at the same time like below.<br /> It&amp;#39;s better to add in rndis_add_response / rndis_free_response<br /> / rndis_get_next_response to prevent any race condition on response list.<br /> <br /> [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption.<br /> next-&gt;prev should be prev (ffffff80651764d0),<br /> but was ffffff883dc36f80. (next=ffffff80651764d0).<br /> <br /> [ 361.904380] [1: irq/191-dwc3:16979] Call trace:<br /> [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90<br /> [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0<br /> [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84<br /> [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4<br /> [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60<br /> [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0<br /> [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc<br /> [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc<br /> [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec<br /> [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c