Vulnerabilidades

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()<br /> <br /> A soft lockup warning was observed on a relative small system x86-64<br /> system with 16 GB of memory when running a debug kernel with kmemleak<br /> enabled.<br /> <br /> watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]<br /> <br /> The test system was running a workload with hot unplug happening in<br /> parallel. Then kemleak decided to disable itself due to its inability to<br /> allocate more kmemleak objects. The debug kernel has its<br /> CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.<br /> <br /> The soft lockup happened in kmemleak_do_cleanup() when the existing<br /> kmemleak objects were being removed and deleted one-by-one in a loop via a<br /> workqueue. In this particular case, there are at least 40,000 objects<br /> that need to be processed and given the slowness of a debug kernel and the<br /> fact that a raw_spinlock has to be acquired and released in<br /> __delete_object(), it could take a while to properly handle all these<br /> objects.<br /> <br /> As kmemleak has been disabled in this case, the object removal and<br /> deletion process can be further optimized as locking isn&amp;#39;t really needed. <br /> However, it is probably not worth the effort to optimize for such an edge<br /> case that should rarely happen. So the simple solution is to call<br /> cond_resched() at periodic interval in the iteration loop to avoid soft<br /> lockup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not allow relocation of partially dropped subvolumes<br /> <br /> [BUG]<br /> There is an internal report that balance triggered transaction abort,<br /> with the following call trace:<br /> <br /> item 85 key (594509824 169 0) itemoff 12599 itemsize 33<br /> extent refs 1 gen 197740 flags 2<br /> ref#0: tree block backref root 7<br /> item 86 key (594558976 169 0) itemoff 12566 itemsize 33<br /> extent refs 1 gen 197522 flags 2<br /> ref#0: tree block backref root 7<br /> ...<br /> BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0<br /> BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117<br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -117)<br /> WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]<br /> <br /> And btrfs check doesn&amp;#39;t report anything wrong related to the extent<br /> tree.<br /> <br /> [CAUSE]<br /> The cause is a little complex, firstly the extent tree indeed doesn&amp;#39;t<br /> have the backref for 594526208.<br /> <br /> The extent tree only have the following two backrefs around that bytenr<br /> on-disk:<br /> <br /> item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33<br /> refs 1 gen 197740 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33<br /> refs 1 gen 197522 flags TREE_BLOCK<br /> tree block skinny level 0<br /> (176 0x7) tree block backref root CSUM_TREE<br /> <br /> But the such missing backref item is not an corruption on disk, as the<br /> offending delayed ref belongs to subvolume 934, and that subvolume is<br /> being dropped:<br /> <br /> item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439<br /> generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328<br /> last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0<br /> drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2<br /> level 2 generation_v2 198229<br /> <br /> And that offending tree block 594526208 is inside the dropped range of<br /> that subvolume. That explains why there is no backref item for that<br /> bytenr and why btrfs check is not reporting anything wrong.<br /> <br /> But this also shows another problem, as btrfs will do all the orphan<br /> subvolume cleanup at a read-write mount.<br /> <br /> So half-dropped subvolume should not exist after an RW mount, and<br /> balance itself is also exclusive to subvolume cleanup, meaning we<br /> shouldn&amp;#39;t hit a subvolume half-dropped during relocation.<br /> <br /> The root cause is, there is no orphan item for this subvolume.<br /> In fact there are 5 subvolumes from around 2021 that have the same<br /> problem.<br /> <br /> It looks like the original report has some older kernels running, and<br /> caused those zombie subvolumes.<br /> <br /> Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot<br /> deletion not triggered on mount") has long fixed the bug.<br /> <br /> [ENHANCEMENT]<br /> For repairing such old fs, btrfs-progs will be enhanced.<br /> <br /> Considering how delayed the problem will show up (at run delayed ref<br /> time) and at that time we have to abort transaction already, it is too<br /> late.<br /> <br /> Instead here we reject any half-dropped subvolume for reloc tree at the<br /> earliest time, preventing confusion and extra time wasted on debugging<br /> similar bugs.

*** Pendiente de traducción *** Under heavy system utilization a random race condition can occur during authentication or token refresh operation. This flaw allows one user to be granted a token intended for another user, resulting in impersonation until the session is ended. This flaw cannot be intentionally exploited due to the required concurring action by two users. However, if the event occurs a user would be inadvertently exposed to another user’s system rights and data access.