Vulnerabilities

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: 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.

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 /> mptcp: ensure snd_nxt is properly initialized on connect<br /> <br /> Christoph reported a splat hinting at a corrupted snd_una:<br /> <br /> WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Modules linked in:<br /> CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8<br /> 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe<br /> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9<br /> RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4<br /> RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000<br /> R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000<br /> FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]<br /> mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]<br /> __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615<br /> mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767<br /> process_one_work+0x1e0/0x560 kernel/workqueue.c:3254<br /> process_scheduled_works kernel/workqueue.c:3335 [inline]<br /> worker_thread+0x3c7/0x640 kernel/workqueue.c:3416<br /> kthread+0x121/0x170 kernel/kthread.c:388<br /> ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243<br /> <br /> <br /> When fallback to TCP happens early on a client socket, snd_nxt<br /> is not yet initialized and any incoming ack will copy such value<br /> into snd_una. If the mptcp worker (dumbly) tries mptcp-level<br /> re-injection after such ack, that would unconditionally trigger a send<br /> buffer cleanup using &amp;#39;bad&amp;#39; snd_una values.<br /> <br /> We could easily disable re-injection for fallback sockets, but such<br /> dumb behavior already helped catching a few subtle issues and a very<br /> low to zero impact in practice.<br /> <br /> Instead address the issue always initializing snd_nxt (and write_seq,<br /> for consistency) at connect time.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix info leak when fetching fw build id<br /> <br /> Add the missing sanity checks and move the 255-byte build-id buffer off<br /> the stack to avoid leaking stack data through debugfs in case the<br /> build-info reply is malformed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix info leak when fetching board id<br /> <br /> Add the missing sanity check when fetching the board id to avoid leaking<br /> slab data when later requesting the firmware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: add missing firmware sanity checks<br /> <br /> Add the missing sanity checks when parsing the firmware files before<br /> downloading them to avoid accessing and corrupting memory beyond the<br /> vmalloced buffer.