Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: make __free(kfree) accept error pointers<br /> <br /> Currently, if an automatically freed allocation is an error pointer that<br /> will lead to a crash. An example of this is in wm831x_gpio_dbg_show().<br /> <br /> 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i);<br /> 172 if (IS_ERR(label)) {<br /> 173 dev_err(wm831x-&gt;dev, "Failed to duplicate label\n");<br /> 174 continue;<br /> 175 }<br /> <br /> The auto clean up function should check for error pointers as well,<br /> otherwise we&amp;#39;re going to keep hitting issues like this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: fix mas_empty_area_rev() null pointer dereference<br /> <br /> Currently the code calls mas_start() followed by mas_data_end() if the<br /> maple state is MA_START, but mas_start() may return with the maple state<br /> node == NULL. This will lead to a null pointer dereference when checking<br /> information in the NULL node, which is done in mas_data_end().<br /> <br /> Avoid setting the offset if there is no node by waiting until after the<br /> maple state is checked for an empty or single entry state.<br /> <br /> A user could trigger the events to cause a kernel oops by unmapping all<br /> vmas to produce an empty maple tree, then mapping a vma that would cause<br /> the scenario described above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: avoid zeroing outside-object freepointer for single free<br /> <br /> Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing<br /> separately") splits single and bulk object freeing in two functions<br /> slab_free() and slab_free_bulk() which leads slab_free() to call<br /> slab_free_hook() directly instead of slab_free_freelist_hook().<br /> <br /> If `init_on_free` is set, slab_free_hook() zeroes the object.<br /> Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are<br /> set, the do_slab_free() slowpath executes freelist consistency<br /> checks and try to decode a zeroed freepointer which leads to a<br /> "Freepointer corrupt" detection in check_object().<br /> <br /> During bulk free, slab_free_freelist_hook() isn&amp;#39;t affected as it always<br /> sets it objects freepointer using set_freepointer() to maintain its<br /> reconstructed freelist after `init_on_free`.<br /> <br /> For single free, object&amp;#39;s freepointer thus needs to be avoided when<br /> stored outside the object if `init_on_free` is set. The freepointer left<br /> as is, check_object() may later detect an invalid pointer value due to<br /> objects overflow.<br /> <br /> To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the<br /> command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.<br /> <br /> dmesg sample log:<br /> [ 10.708715] =============================================================================<br /> [ 10.710323] BUG kmalloc-rnd-05-32 (Tainted: G B T ): Freepointer corrupt<br /> [ 10.712695] -----------------------------------------------------------------------------<br /> [ 10.712695]<br /> [ 10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)<br /> [ 10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c<br /> [ 10.716698]<br /> [ 10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.720703] Object ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.720703] Object ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.724696] Padding ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> [ 10.724696] Padding ffff9d9a8035667c: 00 00 00 00 ....<br /> [ 10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: Check for port partner validity before consuming it<br /> <br /> typec_register_partner() does not guarantee partner registration<br /> to always succeed. In the event of failure, port-&gt;partner is set<br /> to the error value or NULL. Given that port-&gt;partner validity is<br /> not checked, this results in the following crash:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address xx<br /> pc : run_state_machine+0x1bc8/0x1c08<br /> lr : run_state_machine+0x1b90/0x1c08<br /> ..<br /> Call trace:<br /> run_state_machine+0x1bc8/0x1c08<br /> tcpm_state_machine_work+0x94/0xe4<br /> kthread_worker_fn+0x118/0x328<br /> kthread+0x1d0/0x23c<br /> ret_from_fork+0x10/0x20<br /> <br /> To prevent the crash, check for port-&gt;partner validity before<br /> derefencing it in all the call sites.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete<br /> <br /> FFS based applications can utilize the aio_cancel() callback to dequeue<br /> pending USB requests submitted to the UDC. There is a scenario where the<br /> FFS application issues an AIO cancel call, while the UDC is handling a<br /> soft disconnect. For a DWC3 based implementation, the callstack looks<br /> like the following:<br /> <br /> DWC3 Gadget FFS Application<br /> dwc3_gadget_soft_disconnect() ...<br /> --&gt; dwc3_stop_active_transfers()<br /> --&gt; dwc3_gadget_giveback(-ESHUTDOWN)<br /> --&gt; ffs_epfile_async_io_complete() ffs_aio_cancel()<br /> --&gt; usb_ep_free_request() --&gt; usb_ep_dequeue()<br /> <br /> There is currently no locking implemented between the AIO completion<br /> handler and AIO cancel, so the issue occurs if the completion routine is<br /> running in parallel to an AIO cancel call coming from the FFS application.<br /> As the completion call frees the USB request (io_data-&gt;req) the FFS<br /> application is also referencing it for the usb_ep_dequeue() call. This can<br /> lead to accessing a stale/hanging pointer.<br /> <br /> commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status consistently")<br /> relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().<br /> However, in order to properly implement locking to mitigate this issue, the<br /> spinlock can&amp;#39;t be added to ffs_epfile_async_io_complete(), as<br /> usb_ep_dequeue() (if successfully dequeuing a USB request) will call the<br /> function driver&amp;#39;s completion handler in the same context. Hence, leading<br /> into a deadlock.<br /> <br /> Fix this issue by moving the usb_ep_free_request() back to<br /> ffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;req<br /> to NULL after freeing it within the ffs-&gt;eps_lock. This resolves the race<br /> condition above, as the ffs_aio_cancel() routine will not continue<br /> attempting to dequeue a request that has already been freed, or the<br /> ffs_user_copy_work() not freeing the USB request until the AIO cancel is<br /> done referencing it.<br /> <br /> This fix depends on<br /> commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status<br /> consistently")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: use correct buffer size when parsing configfs lists<br /> <br /> This commit fixes uvc gadget support on 32-bit platforms.<br /> <br /> Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for<br /> reuse") introduced a helper function __uvcg_iter_item_entries() to aid<br /> with parsing lists of items on configfs attributes stores. This function<br /> is a generalization of another very similar function, which used a<br /> stack-allocated temporary buffer of fixed size for each item in the list<br /> and used the sizeof() operator to check for potential buffer overruns.<br /> The new function was changed to allocate the now variably sized temp<br /> buffer on heap, but wasn&amp;#39;t properly updated to also check for max buffer<br /> size using the computed size instead of sizeof() operator.<br /> <br /> As a result, the maximum item size was 7 (plus null terminator) on<br /> 64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just<br /> barely enough, 3 is definitely too small for some of UVC configfs<br /> attributes. For example, dwFrameInteval, specified in 100ns units,<br /> usually has 6-digit item values, e.g. 166666 for 60fps.

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 /> tipc: fix UAF in error path<br /> <br /> Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported<br /> a UAF in the tipc_buf_append() error path:<br /> <br /> BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0<br /> linux/net/core/skbuff.c:1183<br /> Read of size 8 at addr ffff88804d2a7c80 by task poc/8034<br /> <br /> CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.0-debian-1.16.0-5 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack linux/lib/dump_stack.c:88<br /> dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106<br /> print_address_description linux/mm/kasan/report.c:377<br /> print_report+0xc4/0x620 linux/mm/kasan/report.c:488<br /> kasan_report+0xda/0x110 linux/mm/kasan/report.c:601<br /> kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183<br /> skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026<br /> skb_release_all linux/net/core/skbuff.c:1094<br /> __kfree_skb linux/net/core/skbuff.c:1108<br /> kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144<br /> kfree_skb linux/./include/linux/skbuff.h:1244<br /> tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186<br /> tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324<br /> tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824<br /> tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159<br /> tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390<br /> udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108<br /> udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186<br /> udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346<br /> __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422<br /> ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233<br /> NF_HOOK linux/./include/linux/netfilter.h:314<br /> NF_HOOK linux/./include/linux/netfilter.h:308<br /> ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254<br /> dst_input linux/./include/net/dst.h:461<br /> ip_rcv_finish linux/net/ipv4/ip_input.c:449<br /> NF_HOOK linux/./include/linux/netfilter.h:314<br /> NF_HOOK linux/./include/linux/netfilter.h:308<br /> ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534<br /> __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648<br /> process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976<br /> __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576<br /> napi_poll linux/net/core/dev.c:6645<br /> net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781<br /> __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553<br /> do_softirq linux/kernel/softirq.c:454<br /> do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441<br /> <br /> <br /> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381<br /> local_bh_enable linux/./include/linux/bottom_half.h:33<br /> rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851<br /> __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378<br /> dev_queue_xmit linux/./include/linux/netdevice.h:3169<br /> neigh_hh_output linux/./include/net/neighbour.h:526<br /> neigh_output linux/./include/net/neighbour.h:540<br /> ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235<br /> __ip_finish_output linux/net/ipv4/ip_output.c:313<br /> __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295<br /> ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323<br /> NF_HOOK_COND linux/./include/linux/netfilter.h:303<br /> ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433<br /> dst_output linux/./include/net/dst.h:451<br /> ip_local_out linux/net/ipv4/ip_output.c:129<br /> ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492<br /> udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963<br /> udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250<br /> inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850<br /> sock_sendmsg_nosec linux/net/socket.c:730<br /> __sock_sendmsg linux/net/socket.c:745<br /> __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191<br /> __do_sys_sendto linux/net/socket.c:2203<br /> __se_sys_sendto linux/net/socket.c:2199<br /> __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199<br /> do_syscall_x64 linux/arch/x86/entry/common.c:52<br /> do_syscall_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer<br /> <br /> Btrfs clears the content of an extent buffer marked as<br /> EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is<br /> introduced to prevent a write hole of an extent buffer, which is once<br /> allocated, marked dirty, but turns out unnecessary and cleaned up within<br /> one transaction operation.<br /> <br /> Currently, btrfs_clear_buffer_dirty() marks the extent buffer as<br /> EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call<br /> happens while the buffer is under IO (with the WRITEBACK flag set,<br /> without the DIRTY flag), we can add the ZEROOUT flag and clear the<br /> buffer&amp;#39;s content just before a bio submission. As a result:<br /> <br /> 1) it can lead to adding faulty delayed reference item which leads to a<br /> FS corrupted (EUCLEAN) error, and<br /> <br /> 2) it writes out cleared tree node on disk<br /> <br /> The former issue is previously discussed in [1]. The corruption happens<br /> when it runs a delayed reference update. So, on-disk data is safe.<br /> <br /> [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/<br /> <br /> The latter one can reach on-disk data. But, as that node is already<br /> processed by btrfs_clear_buffer_dirty(), that will be invalidated in the<br /> next transaction commit anyway. So, the chance of hitting the corruption<br /> is relatively small.<br /> <br /> Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to<br /> keep the content under IO intact.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()<br /> <br /> When I did memory failure tests recently, below warning occurs:<br /> <br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0<br /> Modules linked in: mce_inject hwpoison_inject<br /> CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__lock_acquire+0xccb/0x1ca0<br /> RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082<br /> RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0<br /> RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb<br /> R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10<br /> R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004<br /> FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> lock_acquire+0xbe/0x2d0<br /> _raw_spin_lock_irqsave+0x3a/0x60<br /> hugepage_subpool_put_pages.part.0+0xe/0xc0<br /> free_huge_folio+0x253/0x3f0<br /> dissolve_free_huge_page+0x147/0x210<br /> __page_handle_poison+0x9/0x70<br /> memory_failure+0x4e6/0x8c0<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x380/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xbc/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff9f3114887<br /> RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887<br /> RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001<br /> RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c<br /> R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> panic+0x326/0x350<br /> check_panic_on_warn+0x4f/0x50<br /> __warn+0x98/0x190<br /> report_bug+0x18e/0x1a0<br /> handle_bug+0x3d/0x70<br /> exc_invalid_op+0x18/0x70<br /> asm_exc_invalid_op+0x1a/0x20<br /> RIP: 0010:__lock_acquire+0xccb/0x1ca0<br /> RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082<br /> RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0<br /> RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb<br /> R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10<br /> R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004<br /> lock_acquire+0xbe/0x2d0<br /> _raw_spin_lock_irqsave+0x3a/0x60<br /> hugepage_subpool_put_pages.part.0+0xe/0xc0<br /> free_huge_folio+0x253/0x3f0<br /> dissolve_free_huge_page+0x147/0x210<br /> __page_handle_poison+0x9/0x70<br /> memory_failure+0x4e6/0x8c0<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x380/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xbc/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff9f3114887<br /> RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887<br /> RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001<br /> RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c<br /> R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00<br /> <br /> <br /> After git bisecting and digging into the code, I believe the root cause is<br /> that _deferred_list field of folio is unioned with _hugetlb_subpool field.<br /> In __update_and_free_hugetlb_folio(), folio-&gt;_deferred_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-msm: pervent access to suspended controller<br /> <br /> Generic sdhci code registers LED device and uses host-&gt;runtime_suspended<br /> flag to protect access to it. The sdhci-msm driver doesn&amp;#39;t set this flag,<br /> which causes a crash when LED is accessed while controller is runtime<br /> suspended. Fix this by setting the flag correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: fix the double free in rvu_npc_freemem()<br /> <br /> Clang static checker(scan-build) warning：<br /> drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2<br /> Attempt to free released memory.<br /> <br /> npc_mcam_rsrcs_deinit() has released &amp;#39;mcam-&gt;counters.bmap&amp;#39;. Deleted this<br /> redundant kfree() to fix this double free problem.