Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: lt8912b: Fix crash on bridge detach<br /> <br /> The lt8912b driver, in its bridge detach function, calls<br /> drm_connector_unregister() and drm_connector_cleanup().<br /> <br /> drm_connector_unregister() should be called only for connectors<br /> explicitly registered with drm_connector_register(), which is not the<br /> case in lt8912b.<br /> <br /> The driver&amp;#39;s drm_connector_funcs.destroy hook is set to<br /> drm_connector_cleanup().<br /> <br /> Thus the driver should not call either drm_connector_unregister() nor<br /> drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a<br /> crash on bridge detach:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000096000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000<br /> [0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP<br /> Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks<br /> CPU: 3 PID: 462 Comm: rmmod Tainted: G W 6.5.0-rc2+ #2<br /> Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : drm_connector_cleanup+0x78/0x2d4 [drm]<br /> lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]<br /> sp : ffff800082ed3a90<br /> x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000<br /> x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122<br /> x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8<br /> x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038<br /> x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e<br /> x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48<br /> x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0<br /> x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> drm_connector_cleanup+0x78/0x2d4 [drm]<br /> lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]<br /> drm_bridge_detach+0x44/0x84 [drm]<br /> drm_encoder_cleanup+0x40/0xb8 [drm]<br /> drmm_encoder_alloc_release+0x1c/0x30 [drm]<br /> drm_managed_release+0xac/0x148 [drm]<br /> drm_dev_put.part.0+0x88/0xb8 [drm]<br /> devm_drm_dev_init_release+0x14/0x24 [drm]<br /> devm_action_release+0x14/0x20<br /> release_nodes+0x5c/0x90<br /> devres_release_all+0x8c/0xe0<br /> device_unbind_cleanup+0x18/0x68<br /> device_release_driver_internal+0x208/0x23c<br /> driver_detach+0x4c/0x94<br /> bus_remove_driver+0x70/0xf4<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> tidss_platform_driver_exit+0x18/0xb2c [tidss]<br /> __arm64_sys_delete_module+0x1a0/0x2b4<br /> invoke_syscall+0x48/0x110<br /> el0_svc_common.constprop.0+0x60/0x10c<br /> do_el0_svc_compat+0x1c/0x40<br /> el0_svc_compat+0x40/0xac<br /> el0t_32_sync_handler+0xb0/0x138<br /> el0t_32_sync+0x194/0x198<br /> Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: clk-mt7629: 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 /> perf: hisi: Fix use-after-free when register pmu fails<br /> <br /> When we fail to register the uncore pmu, the pmu context may not been<br /> allocated. The error handing will call cpuhp_state_remove_instance()<br /> to call uncore pmu offline callback, which migrate the pmu context.<br /> Since that&amp;#39;s liable to lead to some kind of use-after-free.<br /> <br /> Use cpuhp_state_remove_instance_nocalls() instead of<br /> cpuhp_state_remove_instance() so that the notifiers don&amp;#39;t execute after<br /> the PMU device has been failed to register.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Fix coverity issue with unintentional integer overflow<br /> <br /> 1. Instead of multiplying 2 variable of different types. Change to<br /> assign a value of one variable and then multiply the other variable.<br /> <br /> 2. Add a int variable for multiplier calculation instead of calculating<br /> different types multiplier with dma_addr_t variable directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Bail out early if the request AUX area is out of bound<br /> <br /> When perf-record with a large AUX area, e.g 4GB, it fails with:<br /> <br /> #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1<br /> failed to mmap with 12 (Cannot allocate memory)<br /> <br /> and it reveals a WARNING with __alloc_pages():<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248<br /> Call trace:<br /> __alloc_pages+0x1ec/0x248<br /> __kmalloc_large_node+0xc0/0x1f8<br /> __kmalloc_node+0x134/0x1e8<br /> rb_alloc_aux+0xe0/0x298<br /> perf_mmap+0x440/0x660<br /> mmap_region+0x308/0x8a8<br /> do_mmap+0x3c0/0x528<br /> vm_mmap_pgoff+0xf4/0x1b8<br /> ksys_mmap_pgoff+0x18c/0x218<br /> __arm64_sys_mmap+0x38/0x58<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x58/0x188<br /> do_el0_svc+0x34/0x50<br /> el0_svc+0x34/0x108<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x1a4/0x1a8<br /> <br /> &amp;#39;rb-&gt;aux_pages&amp;#39; allocated by kcalloc() is a pointer array which is used to<br /> maintains AUX trace pages. The allocated page for this array is physically<br /> contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the<br /> size of pointer array crosses the limitation set by MAX_ORDER, it reveals a<br /> WARNING.<br /> <br /> So bail out early with -ENOMEM if the request AUX area is out of bound,<br /> e.g.:<br /> <br /> #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1<br /> failed to mmap with 12 (Cannot allocate memory)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/ww_mutex/test: Fix potential workqueue corruption<br /> <br /> In some cases running with the test-ww_mutex code, I was seeing<br /> odd behavior where sometimes it seemed flush_workqueue was<br /> returning before all the work threads were finished.<br /> <br /> Often this would cause strange crashes as the mutexes would be<br /> freed while they were being used.<br /> <br /> Looking at the code, there is a lifetime problem as the<br /> controlling thread that spawns the work allocates the<br /> "struct stress" structures that are passed to the workqueue<br /> threads. Then when the workqueue threads are finished,<br /> they free the stress struct that was passed to them.<br /> <br /> Unfortunately the workqueue work_struct node is in the stress<br /> struct. Which means the work_struct is freed before the work<br /> thread returns and while flush_workqueue is waiting.<br /> <br /> It seems like a better idea to have the controlling thread<br /> both allocate and free the stress structures, so that we can<br /> be sure we don&amp;#39;t corrupt the workqueue by freeing the structure<br /> prematurely.<br /> <br /> So this patch reworks the test to do so, and with this change<br /> I no longer see the early flush_workqueue returns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix uaf in nbd_open<br /> <br /> Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and<br /> blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won&amp;#39;t set<br /> disk-&gt;private_data as NULL as before. UAF may be triggered in nbd_open()<br /> if someone tries to open nbd device right after nbd_put() since nbd has<br /> been free in nbd_dev_remove().<br /> <br /> Fix this by implementing -&gt;free_disk and free private data in it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: imsttfb: fix a resource leak in probe<br /> <br /> I&amp;#39;ve re-written the error handling but the bug is that if init_imstt()<br /> fails we need to call iounmap(par-&gt;cmap_regs).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: Do not broadcast to other cpus when starting a counter<br /> <br /> This command:<br /> <br /> $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000<br /> <br /> gives rise to this kernel warning:<br /> <br /> [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436<br /> [ 444.364515] Modules linked in:<br /> [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73<br /> [ 444.364771] Hardware name: riscv-virtio,qemu (DT)<br /> [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436<br /> [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32<br /> [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800<br /> [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0<br /> [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0<br /> [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000<br /> [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100<br /> [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000<br /> [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98<br /> [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000<br /> [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001<br /> [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6<br /> [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0<br /> [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 444.365226] [] smp_call_function_many_cond+0x42c/0x436<br /> [ 444.365295] [] on_each_cpu_cond_mask+0x20/0x32<br /> [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa<br /> [ 444.365327] [] riscv_pmu_start+0x48/0x66<br /> [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac<br /> [ 444.365356] [] perf_event_task_tick+0x78/0x8c<br /> [ 444.365368] [] scheduler_tick+0xe6/0x25e<br /> [ 444.365383] [] update_process_times+0x80/0x96<br /> [ 444.365398] [] tick_sched_handle+0x26/0x52<br /> [ 444.365410] [] tick_sched_timer+0x50/0x98<br /> [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a<br /> [ 444.365433] [] hrtimer_interrupt+0xce/0x1da<br /> [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a<br /> [ 444.365457] [] handle_percpu_devid_irq+0x80/0x114<br /> [ 444.365470] [] generic_handle_domain_irq+0x1c/0x2a<br /> [ 444.365483] [] riscv_intc_irq+0x2e/0x46<br /> [ 444.365497] [] handle_riscv_irq+0x4a/0x74<br /> [ 444.365521] [] do_irq+0x7c/0x7e<br /> [ 444.365796] ---[ end trace 0000000000000000 ]---<br /> <br /> That&amp;#39;s because the fix in commit 3fec323339a4 ("drivers: perf: Fix panic<br /> in riscv SBI mmap support") was wrong since there is no need to broadcast<br /> to other cpus when starting a counter, that&amp;#39;s only needed in mmap when<br /> the counters could have already been started on other cpus, so simply<br /> remove this broadcast.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()<br /> <br /> The put_device() calls rmi_release_function() which frees "fn" so the<br /> dereference on the next line "fn-&gt;num_of_irqs" is a use after free.<br /> Move the put_device() to the end to fix this.