Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Use dynamic allocation for CU occupancy array in &amp;#39;kfd_get_cu_occupancy()&amp;#39;<br /> <br /> The `kfd_get_cu_occupancy` function previously declared a large<br /> `cu_occupancy` array as a local variable, which could lead to stack<br /> overflows due to excessive stack usage. This commit replaces the static<br /> array allocation with dynamic memory allocation using `kcalloc`,<br /> thereby reducing the stack size.<br /> <br /> This change avoids the risk of stack overflows in kernel space, in<br /> scenarios where `AMDGPU_MAX_QUEUES` is large. The allocated memory is<br /> freed using `kfree` before the function returns to prevent memory<br /> leaks.<br /> <br /> Fixes the below with gcc W=1:<br /> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function ‘kfd_get_cu_occupancy’:<br /> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:322:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]<br /> 322 | }<br /> | ^

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()<br /> <br /> kunit_kzalloc() may return a NULL pointer, dereferencing it without<br /> NULL check may lead to NULL dereference.<br /> Add NULL checks for all the kunit_kzalloc() in sound_kunit.c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix recursive lock when verdict program return SK_PASS<br /> <br /> When the stream_verdict program returns SK_PASS, it places the received skb<br /> into its own receive queue, but a recursive lock eventually occurs, leading<br /> to an operating system deadlock. This issue has been present since v6.9.<br /> <br /> &amp;#39;&amp;#39;&amp;#39;<br /> sk_psock_strp_data_ready<br /> write_lock_bh(&amp;sk-&gt;sk_callback_lock)<br /> strp_data_ready<br /> strp_read_sock<br /> read_sock -&gt; tcp_read_sock<br /> strp_recv<br /> cb.rcv_msg -&gt; sk_psock_strp_read<br /> # now stream_verdict return SK_PASS without peer sock assign<br /> __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)<br /> sk_psock_verdict_apply<br /> sk_psock_skb_ingress_self<br /> sk_psock_skb_ingress_enqueue<br /> sk_psock_data_ready<br /> read_lock_bh(&amp;sk-&gt;sk_callback_lock)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on node blkaddr in truncate_node()<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2534!<br /> RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534<br /> Call Trace:<br /> truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909<br /> f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288<br /> f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856<br /> evict+0x4e8/0x9b0 fs/inode.c:723<br /> f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986<br /> f2fs_create+0x357/0x530 fs/f2fs/namei.c:394<br /> lookup_open fs/namei.c:3595 [inline]<br /> open_last_lookups fs/namei.c:3694 [inline]<br /> path_openat+0x1c03/0x3590 fs/namei.c:3930<br /> do_filp_open+0x235/0x490 fs/namei.c:3960<br /> do_sys_openat2+0x13e/0x1d0 fs/open.c:1415<br /> do_sys_open fs/open.c:1430 [inline]<br /> __do_sys_openat fs/open.c:1446 [inline]<br /> __se_sys_openat fs/open.c:1441 [inline]<br /> __x64_sys_openat+0x247/0x2a0 fs/open.c:1441<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534<br /> <br /> The root cause is: on a fuzzed image, blkaddr in nat entry may be<br /> corrupted, then it will cause system panic when using it in<br /> f2fs_invalidate_blocks(), to avoid this, let&amp;#39;s add sanity check on<br /> nat blkaddr in truncate_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device<br /> <br /> While design wise the idea of converting the driver to use<br /> the hierarchy of the IRQ chips is correct, the implementation<br /> has (inherited) flaws. This was unveiled when platform_get_irq()<br /> had started WARN() on IRQ 0 that is supposed to be a Linux<br /> IRQ number (also known as vIRQ).<br /> <br /> Rework the driver to respect IRQ domain when creating each MFD<br /> device separately, as the domain is not the same for all of them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> brd: defer automatic disk creation until module initialization succeeds<br /> <br /> My colleague Wupeng found the following problems during fault injection:<br /> <br /> BUG: unable to handle page fault for address: fffffbfff809d073<br /> PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:__asan_load8+0x4c/0xa0<br /> ...<br /> Call Trace:<br /> <br /> blkdev_put_whole+0x41/0x70<br /> bdev_release+0x1a3/0x250<br /> blkdev_release+0x11/0x20<br /> __fput+0x1d7/0x4a0<br /> task_work_run+0xfc/0x180<br /> syscall_exit_to_user_mode+0x1de/0x1f0<br /> do_syscall_64+0x6b/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> loop_init() is calling loop_add() after __register_blkdev() succeeds and<br /> is ignoring disk_add() failure from loop_add(), for loop_add() failure<br /> is not fatal and successfully created disks are already visible to<br /> bdev_open().<br /> <br /> brd_init() is currently calling brd_alloc() before __register_blkdev()<br /> succeeds and is releasing successfully created disks when brd_init()<br /> returns an error. This can cause UAF for the latter two case:<br /> <br /> case 1:<br /> T1:<br /> modprobe brd<br /> brd_init<br /> brd_alloc(0) // success<br /> add_disk<br /> disk_scan_partitions<br /> bdev_file_open_by_dev // alloc file<br /> fput // won&amp;#39;t free until back to userspace<br /> brd_alloc(1) // failed since mem alloc error inject<br /> // error path for modprobe will release code segment<br /> // back to userspace<br /> __fput<br /> blkdev_release<br /> bdev_release<br /> blkdev_put_whole<br /> bdev-&gt;bd_disk-&gt;fops-&gt;release // fops is freed now, UAF!<br /> <br /> case 2:<br /> T1: T2:<br /> modprobe brd<br /> brd_init<br /> brd_alloc(0) // success<br /> open(/dev/ram0)<br /> brd_alloc(1) // fail<br /> // error path for modprobe<br /> <br /> close(/dev/ram0)<br /> ...<br /> /* UAF! */<br /> bdev-&gt;bd_disk-&gt;fops-&gt;release<br /> <br /> Fix this problem by following what loop_init() does. Besides,<br /> reintroduce brd_devices_mutex to help serialize modifications to<br /> brd_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks &amp;#39;mmio&amp;#39;<br /> <br /> If platform_get_resource_byname() fails and returns NULL because DT lacks<br /> an &amp;#39;mmio&amp;#39; property for the MHI endpoint, dereferencing res-&gt;start will<br /> cause a NULL pointer access. Add a check to prevent it.<br /> <br /> [kwilczynski: error message update per the review feedback]<br /> [bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY<br /> <br /> Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for<br /> PADATA_RESET"), the pcrypt encryption and decryption operations return<br /> -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is<br /> generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns<br /> -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.<br /> Fix this issue by calling crypto layer directly without parallelization<br /> in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: Fix hardware lockup on first Rx endpoint request<br /> <br /> There is a possibility that a request&amp;#39;s callback could be invoked from<br /> usb_ep_queue() (call trace below, supplemented with missing calls):<br /> <br /> req-&gt;complete from usb_gadget_giveback_request<br /> (drivers/usb/gadget/udc/core.c:999)<br /> usb_gadget_giveback_request from musb_g_giveback<br /> (drivers/usb/musb/musb_gadget.c:147)<br /> musb_g_giveback from rxstate<br /> (drivers/usb/musb/musb_gadget.c:784)<br /> rxstate from musb_ep_restart<br /> (drivers/usb/musb/musb_gadget.c:1169)<br /> musb_ep_restart from musb_ep_restart_resume_work<br /> (drivers/usb/musb/musb_gadget.c:1176)<br /> musb_ep_restart_resume_work from musb_queue_resume_work<br /> (drivers/usb/musb/musb_core.c:2279)<br /> musb_queue_resume_work from musb_gadget_queue<br /> (drivers/usb/musb/musb_gadget.c:1241)<br /> musb_gadget_queue from usb_ep_queue<br /> (drivers/usb/gadget/udc/core.c:300)<br /> <br /> According to the docstring of usb_ep_queue(), this should not happen:<br /> <br /> "Note that @req&amp;#39;s -&gt;complete() callback must never be called from within<br /> usb_ep_queue() as that can create deadlock situations."<br /> <br /> In fact, a hardware lockup might occur in the following sequence:<br /> <br /> 1. The gadget is initialized using musb_gadget_enable().<br /> 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an<br /> interrupt.<br /> 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an<br /> empty queue (next_request() returns NULL). The interrupt flag has<br /> already been cleared by the glue layer handler, but the RXPKTRDY flag<br /> remains set.<br /> 4. The first request is enqueued using usb_ep_queue(), leading to the call<br /> of req-&gt;complete(), as shown in the call trace above.<br /> 5. If the callback enables IRQs and another packet is waiting, step (3)<br /> repeats. The request queue is empty because usb_g_giveback() removes the<br /> request before invoking the callback.<br /> 6. The endpoint remains locked up, as the interrupt triggered by hardware<br /> setting the RXPKTRDY flag has been handled, but the flag itself remains<br /> set.<br /> <br /> For this scenario to occur, it is only necessary for IRQs to be enabled at<br /> some point during the complete callback. This happens with the USB Ethernet<br /> gadget, whose rx_complete() callback calls netif_rx(). If called in the<br /> task context, netif_rx() disables the bottom halves (BHs). When the BHs are<br /> re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The<br /> gadget itself is initialized at module load (or at boot if built-in), but<br /> the first request is enqueued when the network interface is brought up,<br /> triggering rx_complete() in the task context via ioctl(). If a packet<br /> arrives while the interface is down, it can prevent the interface from<br /> receiving any further packets from the USB host.<br /> <br /> The situation is quite complicated with many parties involved. This<br /> particular issue can be resolved in several possible ways:<br /> <br /> 1. Ensure that callbacks never enable IRQs. This would be difficult to<br /> enforce, as discovering how netif_rx() interacts with interrupts was<br /> already quite challenging and u_ether is not the only function driver.<br /> Similar "bugs" could be hidden in other drivers as well.<br /> 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback<br /> and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),<br /> for example). This would ensure that MUSB interrupts are not handled<br /> during the callback, even if IRQs are enabled. In fact, it would allow<br /> IRQs to be enabled when releasing the lock. However, this feels like an<br /> inelegant hack.<br /> 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request<br /> queue is empty. While this approach also feels like a hack, it wastes<br /> CPU time by attempting to handle incoming packets when the software is<br /> not ready to process them.<br /> 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().<br /> This ensures that the hardware can receive packets when there is at<br /> least one request in the queue. Once I<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport<br /> <br /> Since transport-&gt;sock has been set to NULL during reset transport,<br /> XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the<br /> xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()<br /> to dereference the transport-&gt;sock that has been set to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()<br /> <br /> It should be size of the struct clk_bulk_data, not data pointer pass to<br /> devm_kcalloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe<br /> <br /> Following commit 13f58267cda3 ("ASoC: soc.h: don&amp;#39;t create dummy<br /> Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero<br /> length, and only gets populated with the dummy struct after the card is<br /> registered. Since the sound card driver&amp;#39;s probe happens before the card<br /> registration, accessing any of the members of a dummy component during<br /> probe will result in undefined behavior.<br /> <br /> This can be observed in the mt8188 and mt8195 machine sound drivers. By<br /> omitting a dai link subnode in the sound card&amp;#39;s node in the Devicetree,<br /> the default uninitialized dummy codec is used, and when its dai_name<br /> pointer gets passed to strcmp() it results in a null pointer dereference<br /> and a kernel panic.<br /> <br /> In addition to that, set_card_codec_info() in the generic helpers file,<br /> mtk-soundcard-driver.c, will populate a dai link with a dummy codec when<br /> a dai link node is present in DT but with no codec property.<br /> <br /> The result is that at probe time, a dummy codec can either be<br /> uninitialized with num_codecs = 0, or be an initialized dummy codec,<br /> with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to<br /> accommodate for both situations, check that num_codecs is not zero<br /> before accessing the codecs&amp;#39; fields but still check for the codec&amp;#39;s dai<br /> name against "snd-soc-dummy-dai" as needed.<br /> <br /> While at it, also drop the check that dai_name is not null in the mt8192<br /> driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192:<br /> Check existence of dai_name before dereferencing"), as it is actually<br /> redundant given the preceding num_codecs != 0 check.