Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: prevent potential string overflow<br /> <br /> The dev-&gt;id value comes from ida_alloc() so it&amp;#39;s a number between zero<br /> and INT_MAX. If it&amp;#39;s too high then these sprintf()s will overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/platform: Add check for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data<br /> <br /> Add the check for the return value of mtk_alloc_clk_data() in order to<br /> avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: llcc: Handle a second device without data corruption<br /> <br /> Usually there is only one llcc device. But if there were a second, even<br /> a failed probe call would modify the global drv_data pointer. So check<br /> if drv_data is valid before overwriting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: fix race condition in status line change on dead connections<br /> <br /> gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all<br /> timers, removing the virtual tty devices and clearing the data queues.<br /> This procedure, however, may cause subsequent changes of the virtual modem<br /> status lines of a DLCI. More data is being added the outgoing data queue<br /> and the deleted kick timer is restarted to handle this. At this point many<br /> resources have already been removed by the cleanup procedure. Thus, a<br /> kernel panic occurs.<br /> <br /> Fix this by proving in gsm_modem_update() that the cleanup procedure has<br /> not been started and the mux is still alive.<br /> <br /> Note that writing to a virtual tty is already protected by checks against<br /> the DLCI specific connection state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/mem: Fix shutdown order<br /> <br /> Ira reports that removing cxl_mock_mem causes a crash with the following<br /> trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000044<br /> [..]<br /> RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_region_detach+0xe8/0x210 [cxl_core]<br /> cxl_decoder_kill_region+0x27/0x40 [cxl_core]<br /> cxld_unregister+0x29/0x40 [cxl_core]<br /> devres_release_all+0xb8/0x110<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1d2/0x210<br /> bus_remove_device+0xd7/0x150<br /> device_del+0x155/0x3e0<br /> device_unregister+0x13/0x60<br /> devm_release_action+0x4d/0x90<br /> ? __pfx_unregister_port+0x10/0x10 [cxl_core]<br /> delete_endpoint+0x121/0x130 [cxl_core]<br /> devres_release_all+0xb8/0x110<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1d2/0x210<br /> bus_remove_device+0xd7/0x150<br /> device_del+0x155/0x3e0<br /> ? lock_release+0x142/0x290<br /> cdev_device_del+0x15/0x50<br /> cxl_memdev_unregister+0x54/0x70 [cxl_core]<br /> <br /> This crash is due to the clearing out the cxl_memdev&amp;#39;s driver context<br /> (@cxlds) before the subsystem is done with it. This is ultimately due to<br /> the region(s), that this memdev is a member, being torn down and expecting<br /> to be able to de-reference @cxlds, like here:<br /> <br /> static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)<br /> ...<br /> if (cxlds-&gt;rcd)<br /> goto endpoint_reset;<br /> ...<br /> <br /> Fix it by keeping the driver context valid until memdev-device<br /> unregistration, and subsequently the entire stack of related<br /> dependencies, unwinds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hantro: Check whether reset op is defined before use<br /> <br /> The i.MX8MM/N/P does not define the .reset op since reset of the VPU is<br /> done by genpd. Check whether the .reset op is defined before calling it<br /> to avoid NULL pointer dereference.<br /> <br /> Note that the Fixes tag is set to the commit which removed the reset op<br /> from i.MX8M Hantro G2 implementation, this is because before this commit<br /> all the implementations did define the .reset op.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF<br /> <br /> In the unlikely event that workqueue allocation fails and returns NULL in<br /> mlx5_mkey_cache_init(), delete the call to<br /> mlx5r_umr_resource_cleanup() (which frees the QP) in<br /> mlx5_ib_stage_post_ib_reg_umr_init(). This will avoid attempted double<br /> free of the same QP when __mlx5_ib_add() does its cleanup.<br /> <br /> Resolves a splat:<br /> <br /> Syzkaller reported a UAF in ib_destroy_qp_user<br /> <br /> workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR<br /> infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):<br /> failed to create work queue<br /> infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):<br /> mr cache init failed -12<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)<br /> Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642<br /> <br /> Call Trace:<br /> <br /> kasan_report (mm/kasan/report.c:590)<br /> ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)<br /> mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...<br /> <br /> <br /> Allocated by task 1642:<br /> __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026<br /> mm/slab_common.c:1039)<br /> create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720<br /> ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209)<br /> ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347)<br /> mlx5r_umr_resource_init (drivers/infiniband/hw/mlx5/umr.c:164)<br /> mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...<br /> <br /> Freed by task 1642:<br /> __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822)<br /> ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2112)<br /> mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)<br /> mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076<br /> drivers/infiniband/hw/mlx5/main.c:4065)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to avoid use-after-free on dic<br /> <br /> Call trace:<br /> __memcpy+0x128/0x250<br /> f2fs_read_multi_pages+0x940/0xf7c<br /> f2fs_mpage_readpages+0x5a8/0x624<br /> f2fs_readahead+0x5c/0x110<br /> page_cache_ra_unbounded+0x1b8/0x590<br /> do_sync_mmap_readahead+0x1dc/0x2e4<br /> filemap_fault+0x254/0xa8c<br /> f2fs_filemap_fault+0x2c/0x104<br /> __do_fault+0x7c/0x238<br /> do_handle_mm_fault+0x11bc/0x2d14<br /> do_mem_abort+0x3a8/0x1004<br /> el0_da+0x3c/0xa0<br /> el0t_64_sync_handler+0xc4/0xec<br /> el0t_64_sync+0x1b4/0x1b8<br /> <br /> In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if<br /> we hit cached page in compress_inode&amp;#39;s cache, dic may be released, it needs<br /> break the loop rather than continuing it, in order to avoid accessing<br /> invalid dic pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hid: cp2112: Fix duplicate workqueue initialization<br /> <br /> Previously the cp2112 driver called INIT_DELAYED_WORK within<br /> cp2112_gpio_irq_startup, resulting in duplicate initilizations of the<br /> workqueue on subsequent IRQ startups following an initial request. This<br /> resulted in a warning in set_work_data in workqueue.c, as well as a rare<br /> NULL dereference within process_one_work in workqueue.c.<br /> <br /> Initialize the workqueue within _probe instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: Fix refcnt handling in padata_free_shell()<br /> <br /> In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead<br /> to system UAF (Use-After-Free) issues. Due to the lengthy analysis of<br /> the pcrypt_aead01 function call, I&amp;#39;ll describe the problem scenario<br /> using a simplified model:<br /> <br /> Suppose there&amp;#39;s a user of padata named `user_function` that adheres to<br /> the padata requirement of calling `padata_free_shell` after `serial()`<br /> has been invoked, as demonstrated in the following code:<br /> <br /> ```c<br /> struct request {<br /> struct padata_priv padata;<br /> struct completion *done;<br /> };<br /> <br /> void parallel(struct padata_priv *padata) {<br /> do_something();<br /> }<br /> <br /> void serial(struct padata_priv *padata) {<br /> struct request *request = container_of(padata,<br /> struct request,<br /> padata);<br /> complete(request-&gt;done);<br /> }<br /> <br /> void user_function() {<br /> DECLARE_COMPLETION(done)<br /> padata-&gt;parallel = parallel;<br /> padata-&gt;serial = serial;<br /> padata_do_parallel();<br /> wait_for_completion(&amp;done);<br /> padata_free_shell();<br /> }<br /> ```<br /> <br /> In the corresponding padata.c file, there&amp;#39;s the following code:<br /> <br /> ```c<br /> static void padata_serial_worker(struct work_struct *serial_work) {<br /> ...<br /> cnt = 0;<br /> <br /> while (!list_empty(&amp;local_list)) {<br /> ...<br /> padata-&gt;serial(padata);<br /> cnt++;<br /> }<br /> <br /> local_bh_enable();<br /> <br /> if (refcount_sub_and_test(cnt, &amp;pd-&gt;refcnt))<br /> padata_free_pd(pd);<br /> }<br /> ```<br /> <br /> Because of the high system load and the accumulation of unexecuted<br /> softirq at this moment, `local_bh_enable()` in padata takes longer<br /> to execute than usual. Subsequently, when accessing `pd-&gt;refcnt`,<br /> `pd` has already been released by `padata_free_shell()`, resulting<br /> in a UAF issue with `pd-&gt;refcnt`.<br /> <br /> The fix is straightforward: add `refcount_dec_and_test` before calling<br /> `padata_free_pd` in `padata_free_shell`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency<br /> <br /> In _dwc2_hcd_urb_enqueue(), "urb-&gt;hcpriv = NULL" is executed without<br /> holding the lock "hsotg-&gt;lock". In _dwc2_hcd_urb_dequeue():<br /> <br /> spin_lock_irqsave(&amp;hsotg-&gt;lock, flags);<br /> ...<br /> if (!urb-&gt;hcpriv) {<br /> dev_dbg(hsotg-&gt;dev, "## urb-&gt;hcpriv is NULL ##\n");<br /> goto out;<br /> }<br /> rc = dwc2_hcd_urb_dequeue(hsotg, urb-&gt;hcpriv); // Use urb-&gt;hcpriv<br /> ...<br /> out:<br /> spin_unlock_irqrestore(&amp;hsotg-&gt;lock, flags);<br /> <br /> When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are<br /> concurrently executed, the NULL check of "urb-&gt;hcpriv" can be executed<br /> before "urb-&gt;hcpriv = NULL". After urb-&gt;hcpriv is NULL, it can be used<br /> in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL<br /> pointer dereference.<br /> <br /> This possible bug is found by an experimental static analysis tool<br /> developed by myself. This tool analyzes the locking APIs to extract<br /> function pairs that can be concurrently executed, and then analyzes the<br /> instructions in the paired functions to identify possible concurrency<br /> bugs including data races and atomicity violations. The above possible<br /> bug is reported, when my tool analyzes the source code of Linux 6.5.<br /> <br /> To fix this possible bug, "urb-&gt;hcpriv = NULL" should be executed with<br /> holding the lock "hsotg-&gt;lock". After using this patch, my tool never<br /> reports the possible bug, with the kernelconfiguration allyesconfig for<br /> x86_64. Because I have no associated hardware, I cannot test the patch<br /> in runtime testing, and just verify it according to the code logic.