Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Correct tid cleanup when tid setup fails<br /> <br /> Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(),<br /> the tid value is already incremented, even though the corresponding<br /> TID is not actually allocated. Proceed to<br /> ath12k_dp_rx_peer_tid_delete() starting from unallocated tid,<br /> which might leads to freeing unallocated TID and cause potential<br /> crash or out-of-bounds access.<br /> <br /> Hence, fix by correctly decrementing tid before cleanup to match only<br /> the successfully allocated TIDs.<br /> <br /> Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(),<br /> as decrementing the tid before cleanup in loop will take care of this.<br /> <br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Forget ranges when refining tnum after JSET<br /> <br /> Syzbot reported a kernel warning due to a range invariant violation on<br /> the following BPF program.<br /> <br /> 0: call bpf_get_netns_cookie<br /> 1: if r0 == 0 goto <br /> 2: if r0 &amp; Oxffffffff goto <br /> <br /> The issue is on the path where we fall through both jumps.<br /> <br /> That path is unreachable at runtime: after insn 1, we know r0 != 0, but<br /> with the sign extension on the jset, we would only fallthrough insn 2<br /> if r0 == 0. Unfortunately, is_branch_taken() isn&amp;#39;t currently able to<br /> figure this out, so the verifier walks all branches. The verifier then<br /> refines the register bounds using the second condition and we end<br /> up with inconsistent bounds on this unreachable path:<br /> <br /> 1: if r0 == 0 goto <br /> r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff)<br /> 2: if r0 &amp; 0xffffffff goto <br /> r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0)<br /> r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0)<br /> <br /> Improving the range refinement for JSET to cover all cases is tricky. We<br /> also don&amp;#39;t expect many users to rely on JSET given LLVM doesn&amp;#39;t generate<br /> those instructions. So instead of improving the range refinement for<br /> JSETs, Eduard suggested we forget the ranges whenever we&amp;#39;re narrowing<br /> tnums after a JSET. This patch implements that approach.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Protect -&gt;defer_qs_iw_pending from data race<br /> <br /> On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is<br /> invoked within an interrupts-disabled region of code [1], it will invoke<br /> rcu_read_unlock_special(), which uses an irq-work handler to force the<br /> system to notice when the RCU read-side critical section actually ends.<br /> That end won&amp;#39;t happen until interrupts are enabled at the soonest.<br /> <br /> In some kernels, such as those booted with rcutree.use_softirq=y, the<br /> irq-work handler is used unconditionally.<br /> <br /> The per-CPU rcu_data structure&amp;#39;s -&gt;defer_qs_iw_pending field is<br /> updated by the irq-work handler and is both read and updated by<br /> rcu_read_unlock_special(). This resulted in the following KCSAN splat:<br /> <br /> ------------------------------------------------------------------------<br /> <br /> BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special<br /> <br /> read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:<br /> rcu_read_unlock_special+0x175/0x260<br /> __rcu_read_unlock+0x92/0xa0<br /> rt_spin_unlock+0x9b/0xc0<br /> __local_bh_enable+0x10d/0x170<br /> __local_bh_enable_ip+0xfb/0x150<br /> rcu_do_batch+0x595/0xc40<br /> rcu_cpu_kthread+0x4e9/0x830<br /> smpboot_thread_fn+0x24d/0x3b0<br /> kthread+0x3bd/0x410<br /> ret_from_fork+0x35/0x40<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:<br /> rcu_preempt_deferred_qs_handler+0x1e/0x30<br /> irq_work_single+0xaf/0x160<br /> run_irq_workd+0x91/0xc0<br /> smpboot_thread_fn+0x24d/0x3b0<br /> kthread+0x3bd/0x410<br /> ret_from_fork+0x35/0x40<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> no locks held by irq_work/8/88.<br /> irq event stamp: 200272<br /> hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320<br /> hardirqs last disabled at (200271): [] __schedule+0x129/0xd70<br /> softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0<br /> softirqs last disabled at (0): [] 0x0<br /> <br /> ------------------------------------------------------------------------<br /> <br /> The problem is that irq-work handlers run with interrupts enabled, which<br /> means that rcu_preempt_deferred_qs_handler() could be interrupted,<br /> and that interrupt handler might contain an RCU read-side critical<br /> section, which might invoke rcu_read_unlock_special(). In the strict<br /> KCSAN mode of operation used by RCU, this constitutes a data race on<br /> the -&gt;defer_qs_iw_pending field.<br /> <br /> This commit therefore disables interrupts across the portion of the<br /> rcu_preempt_deferred_qs_handler() that updates the -&gt;defer_qs_iw_pending<br /> field. This suffices because this handler is not a fast path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: rockchip: fix kernel hang during smp initialization<br /> <br /> In order to bring up secondary CPUs main CPU write trampoline<br /> code to SRAM. The trampoline code is written while secondary<br /> CPUs are powered on (at least that true for RK3188 CPU).<br /> Sometimes that leads to kernel hang. Probably because secondary<br /> CPU execute trampoline code while kernel doesn&amp;#39;t expect.<br /> <br /> The patch moves SRAM initialization step to the point where all<br /> secondary CPUs are powered down.<br /> <br /> That fixes rarely hangs on RK3188:<br /> [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000<br /> [ 0.091996] rockchip_smp_prepare_cpus: ncores 4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: shutdown driver when hardware is unreliable<br /> <br /> In rare cases, ath10k may lose connection with the PCIe bus due to<br /> some unknown reasons, which could further lead to system crashes during<br /> resuming due to watchdog timeout:<br /> <br /> ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware<br /> ath10k_pci 0000:01:00.0: already restarting<br /> ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11<br /> ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11<br /> ieee80211 phy0: PM: **** DPM device timeout ****<br /> Call Trace:<br /> panic+0x125/0x315<br /> dpm_watchdog_set+0x54/0x54<br /> dpm_watchdog_handler+0x57/0x57<br /> call_timer_fn+0x31/0x13c<br /> <br /> At this point, all WMI commands will timeout and attempt to restart<br /> device. So set a threshold for consecutive restart failures. If the<br /> threshold is exceeded, consider the hardware is unreliable and all<br /> ath10k operations should be skipped to avoid system crash.<br /> <br /> fail_cont_count and pending_recovery are atomic variables, and<br /> do not involve complex conditional logic. Therefore, even if recovery<br /> check and reconfig complete are executed concurrently, the recovery<br /> mechanism will not be broken.<br /> <br /> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Fix rcu_read_unlock() deadloop due to IRQ work<br /> <br /> During rcu_read_unlock_special(), if this happens during irq_exit(), we<br /> can lockup if an IPI is issued. This is because the IPI itself triggers<br /> the irq_exit() path causing a recursive lock up.<br /> <br /> This is precisely what Xiongfeng found when invoking a BPF program on<br /> the trace_tick_stop() tracepoint As shown in the trace below. Fix by<br /> managing the irq_work state correctly.<br /> <br /> irq_exit()<br /> __irq_exit_rcu()<br /> /* in_hardirq() returns false after this */<br /> preempt_count_sub(HARDIRQ_OFFSET)<br /> tick_irq_exit()<br /> tick_nohz_irq_exit()<br /> tick_nohz_stop_sched_tick()<br /> trace_tick_stop() /* a bpf prog is hooked on this trace point */<br /> __bpf_trace_tick_stop()<br /> bpf_trace_run2()<br /> rcu_read_unlock_special()<br /> /* will send a IPI to itself */<br /> irq_work_queue_on(&amp;rdp-&gt;defer_qs_iw, rdp-&gt;cpu);<br /> <br /> A simple reproducer can also be obtained by doing the following in<br /> tick_irq_exit(). It will hang on boot without the patch:<br /> <br /> static inline void tick_irq_exit(void)<br /> {<br /> + rcu_read_lock();<br /> + WRITE_ONCE(current-&gt;rcu_read_unlock_special.b.need_qs, true);<br /> + rcu_read_unlock();<br /> +<br /> <br /> [neeraj: Apply Frederic&amp;#39;s suggested fix for PREEMPT_RT]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcutorture: Fix rcutorture_one_extend_check() splat in RT kernels<br /> <br /> For built with CONFIG_PREEMPT_RT=y kernels, running rcutorture<br /> tests resulted in the following splat:<br /> <br /> [ 68.797425] rcutorture_one_extend_check during change: Current 0x1 To add 0x1 To remove 0x0 preempt_count() 0x0<br /> [ 68.797533] WARNING: CPU: 2 PID: 512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture]<br /> [ 68.797601] Call Trace:<br /> [ 68.797602] <br /> [ 68.797619] ? lockdep_softirqs_off+0xa5/0x160<br /> [ 68.797631] rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]<br /> [ 68.797646] ? local_clock+0x19/0x40<br /> [ 68.797659] rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]<br /> [ 68.797678] ? __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]<br /> [ 68.797804] ? __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]<br /> [ 68.797815] rcu-torture: rcu_torture_reader task started<br /> [ 68.797824] rcu-torture: Creating rcu_torture_reader task<br /> [ 68.797824] rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]<br /> [ 68.797836] ? kvm_sched_clock_read+0x15/0x30<br /> <br /> Disable BH does not change the SOFTIRQ corresponding bits in<br /> preempt_count() for RT kernels, this commit therefore use<br /> softirq_count() to check the if BH is disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: truncate good inode pages when hard link is 0<br /> <br /> The fileset value of the inode copy from the disk by the reproducer is<br /> AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its<br /> inode pages are not truncated. This causes the bugon to be triggered when<br /> executing clear_inode() because nrpages is greater than 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/migrate: prevent potential UAF<br /> <br /> If we hit the error path, the previous fence (if there is one) has<br /> already been put() prior to this, so doing a fence_wait could lead to<br /> UAF. Tweak the flow to do to the put() until after we do the wait.<br /> <br /> (cherry picked from commit 9b7ca35ed28fe5fad86e9d9c24ebd1271e4c9c3e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/migrate: don&amp;#39;t overflow max copy size<br /> <br /> With non-page aligned copy, we need to use 4 byte aligned pitch, however<br /> the size itself might still be close to our maximum of ~8M, and so the<br /> dimensions of the copy can easily exceed the S16_MAX limit of the copy<br /> command leading to the following assert:<br /> <br /> xe 0000:03:00.0: [drm] Assertion `size / pitch &gt; 1))` failed!<br /> platform: BATTLEMAGE subplatform: 1<br /> graphics: Xe2_HPG 20.01 step A0<br /> media: Xe2_HPM 13.01 step A1<br /> tile: 0 VRAM 10.0 GiB<br /> GT: 0 type 1<br /> <br /> WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe]<br /> <br /> To fix this account for the pitch when calculating the number of current<br /> bytes to copy.<br /> <br /> (cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()<br /> <br /> The function divides number of online CPUs by num_core_siblings, and<br /> later checks the divider by zero. This implies a possibility to get<br /> and divide-by-zero runtime error. Fix it by moving the check prior to<br /> division. This also helps to save one indentation level.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-qcom: Add SM6115 MDSS compatible<br /> <br /> Add the SM6115 MDSS compatible to clients compatible list, as it also<br /> needs that workaround.<br /> Without this workaround, for example, QRB4210 RB2 which is based on<br /> SM4250/SM6115 generates a lot of smmu unhandled context faults during<br /> boot:<br /> <br /> arm_smmu_context_fault: 116854 callbacks suppressed<br /> arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,<br /> iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5<br /> arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420<br /> arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]<br /> arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,<br /> iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5<br /> arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420<br /> <br /> and also failed initialisation of lontium lt9611uxc, gpu and dpu is<br /> observed:<br /> (binding MDSS components triggered by lt9611uxc have failed)<br /> <br /> ------------[ cut here ]------------<br /> !aspace<br /> WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]<br /> Modules linked in: ... (long list of modules)<br /> CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT<br /> Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : msm_gem_vma_init+0x150/0x18c [msm]<br /> lr : msm_gem_vma_init+0x150/0x18c [msm]<br /> sp : ffff80008144b280<br /> ...<br /> Call trace:<br /> msm_gem_vma_init+0x150/0x18c [msm] (P)<br /> get_vma_locked+0xc0/0x194 [msm]<br /> msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]<br /> msm_gem_kernel_new+0x48/0x160 [msm]<br /> msm_gpu_init+0x34c/0x53c [msm]<br /> adreno_gpu_init+0x1b0/0x2d8 [msm]<br /> a6xx_gpu_init+0x1e8/0x9e0 [msm]<br /> adreno_bind+0x2b8/0x348 [msm]<br /> component_bind_all+0x100/0x230<br /> msm_drm_bind+0x13c/0x3d0 [msm]<br /> try_to_bring_up_aggregate_device+0x164/0x1d0<br /> __component_add+0xa4/0x174<br /> component_add+0x14/0x20<br /> dsi_dev_attach+0x20/0x34 [msm]<br /> dsi_host_attach+0x58/0x98 [msm]<br /> devm_mipi_dsi_attach+0x34/0x90<br /> lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]<br /> lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]<br /> i2c_device_probe+0x148/0x2a8<br /> really_probe+0xbc/0x2c0<br /> __driver_probe_device+0x78/0x120<br /> driver_probe_device+0x3c/0x154<br /> __driver_attach+0x90/0x1a0<br /> bus_for_each_dev+0x68/0xb8<br /> driver_attach+0x24/0x30<br /> bus_add_driver+0xe4/0x208<br /> driver_register+0x68/0x124<br /> i2c_register_driver+0x48/0xcc<br /> lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]<br /> do_one_initcall+0x60/0x1d4<br /> do_init_module+0x54/0x1fc<br /> load_module+0x1748/0x1c8c<br /> init_module_from_file+0x74/0xa0<br /> __arm64_sys_finit_module+0x130/0x2f8<br /> invoke_syscall+0x48/0x104<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x2c/0x80<br /> el0t_64_sync_handler+0x10c/0x138<br /> el0t_64_sync+0x198/0x19c<br /> ---[ end trace 0000000000000000 ]---<br /> msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22<br /> msm_dpu 5e01000.display-controller: failed to load adreno gpu<br /> platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19<br /> msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22<br /> msm_dpu 5e01000.display-controller: adev bind failed: -22<br /> lt9611uxc 0-002b: failed to attach dsi to host<br /> lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22