Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()<br /> <br /> In idpf_ptp_init(), read_dev_clk_lock is initialized after<br /> ptp_schedule_worker() had already been called (and after<br /> idpf_ptp_settime64() could reach the lock). The PTP aux worker<br /> fires immediately upon scheduling and can call into<br /> idpf_ptp_read_src_clk_reg_direct(), which takes<br /> spin_lock(&amp;ptp-&gt;read_dev_clk_lock) on an uninitialized lock, triggering<br /> the lockdep "non-static key" warning:<br /> <br /> [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated<br /> [12974.094507] INFO: trying to register non-static key.<br /> ...<br /> [12974.097208] Call Trace:<br /> [12974.097213] <br /> [12974.097218] dump_stack_lvl+0x93/0xe0<br /> [12974.097234] register_lock_class+0x4c4/0x4e0<br /> [12974.097249] ? __lock_acquire+0x427/0x2290<br /> [12974.097259] __lock_acquire+0x98/0x2290<br /> [12974.097272] lock_acquire+0xc6/0x310<br /> [12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190<br /> [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350<br /> [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp]<br /> [12974.097343] _raw_spin_lock+0x30/0x40<br /> [12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]<br /> [12974.097391] ? kthread_worker_fn+0x88/0x3d0<br /> [12974.097404] ? kthread_worker_fn+0x4e/0x3d0<br /> [12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf]<br /> [12974.097428] ? _raw_spin_unlock_irq+0x28/0x50<br /> [12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf]<br /> [12974.097454] ptp_aux_kworker+0x20/0x40 [ptp]<br /> [12974.097464] kthread_worker_fn+0xd5/0x3d0<br /> [12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [12974.097482] kthread+0xf4/0x130<br /> [12974.097489] ? __pfx_kthread+0x10/0x10<br /> [12974.097498] ret_from_fork+0x32c/0x410<br /> [12974.097512] ? __pfx_kthread+0x10/0x10<br /> [12974.097519] ret_from_fork_asm+0x1a/0x30<br /> [12974.097540] <br /> <br /> Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock<br /> is not touched before it&amp;#39;s been initialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> test_kprobes: clear kprobes between test runs<br /> <br /> Running the kprobes sanity tests twice makes all tests fail and<br /> eventually crashes the kernel.<br /> <br /> [root@martin-riscv-1 ~]# echo 1 &gt; /sys/kernel/debug/kunit/kprobes_test/run<br /> ...<br /> # Totals: pass:5 fail:0 skip:0 total:5<br /> ok 1 kprobes_test<br /> [root@martin-riscv-1 ~]# echo 1 &gt; /sys/kernel/debug/kunit/kprobes_test/run<br /> ...<br /> # test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64<br /> Expected 0 == register_kprobe(&amp;kp), but<br /> register_kprobe(&amp;kp) == -22 (0xffffffffffffffea)<br /> ...<br /> Unable to handle kernel paging request ...<br /> <br /> The testsuite defines several kprobes and kretprobes as static variables<br /> that are preserved across test runs.<br /> <br /> After register_kprobe and unregister_kprobe, a kprobe contains some<br /> leftover data that must be cleared before the kprobe can be registered<br /> again. The tests are setting symbol_name to define the probe location.<br /> Address and flags must be cleared.<br /> <br /> The existing code clears some of the probes between subsequent tests, but<br /> not between two test runs. The leftover data from a previous test run<br /> makes the registrations fail in the next run.<br /> <br /> Move the cleanups for all kprobes into kprobes_test_init, this function<br /> is called before each single test (including the first test of a test<br /> run).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file()<br /> <br /> The trace event btrfs_sync_file() is called in an atomic context (all trace<br /> events are) and its call to dput(), which is needed due to the call to<br /> dget_parent(), can sleep, triggering a kernel splat.<br /> <br /> This can be reproduced by enabling the trace event and running btrfs/056<br /> from fstests for example. The splat shown in dmesg is the following:<br /> <br /> [53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970<br /> [53.947] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 32773, name: xfs_io<br /> [53.988] preempt_count: 2, expected: 0<br /> [53.967] RCU nest depth: 0, expected: 0<br /> [53.943] Preemption disabled at:<br /> [53.944] [] 0x0<br /> [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfs_io Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full)<br /> [54.070] Tainted: [W]=WARN<br /> [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [54.072] Call Trace:<br /> [54.074] <br /> [54.076] dump_stack_lvl+0x56/0x80<br /> [54.079] __might_resched.cold+0xd6/0x10f<br /> [54.072] dput.part.0+0x24/0x110<br /> [54.078] trace_event_raw_event_btrfs_sync_file+0x75/0x140 [btrfs]<br /> [54.089] btrfs_sync_file+0x1ed/0x530 [btrfs]<br /> [54.087] ? __handle_mm_fault+0x8ae/0xed0<br /> [54.089] btrfs_do_write_iter+0x172/0x210 [btrfs]<br /> [54.091] vfs_write+0x21f/0x450<br /> [54.094] __x64_sys_pwrite64+0x8d/0xc0<br /> [54.096] ? do_user_addr_fault+0x20c/0x670<br /> [54.099] do_syscall_64+0x60/0xf20<br /> [54.092] ? clear_bhb_loop+0x60/0xb0<br /> [54.094] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> So stop using dget_parent() and dput() and access the parent dentry<br /> directly as dentry-&gt;d_parent. This is also what ext4 is doing in<br /> its equivalent trace event ext4_sync_file_enter().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: integrator: Fix early initialization<br /> <br /> Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using<br /> syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible<br /> which in turn calls of_syscon_register. This function allocates memory.<br /> Since the memory management code has not been initialized at that time,<br /> the call always fails. It either returns -ENOMEM or crashes as follows.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read<br /> [0000000c] *pgd=00000000<br /> Internal error: Oops: 5 [#1] ARM<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT<br /> Hardware name: ARM Integrator/CP (Device Tree)<br /> PC is at __kmalloc_cache_noprof+0xec/0x39c<br /> LR is at __kmalloc_cache_noprof+0x34/0x39c<br /> ...<br /> Call trace:<br /> __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310<br /> of_syscon_register from device_node_get_regmap+0xa4/0xb0<br /> device_node_get_regmap from intcp_init_early+0xc/0x40<br /> intcp_init_early from start_kernel+0x60/0x688<br /> start_kernel from 0x0<br /> <br /> The crash is seen due to a dereferenced pointer which is not supposed to be<br /> NULL but is NULL if the memory management subsystem has not been<br /> initialized. The crash is not seen with all versions of gcc. Some versions<br /> such as gcc 9.x apparently do not dereference the pointer, presumably if<br /> tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x,<br /> and 13.x. Either case, if the crash is not seen, the call to<br /> syscon_regmap_lookup_by_compatible returns -ENOMEM, and<br /> sched_clock_register is never called.<br /> <br /> Fix the problem by moving the early initialization code into the standard<br /> machine initialization code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Check for NULL FF-A ID table while driver registration<br /> <br /> The bus match callback assumes that every FF-A driver provides an<br /> id_table and dereferences it unconditionally. Enforce that contract at<br /> registration time so a buggy client driver cannot crash the bus during<br /> match.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kho: skip KHO for crash kernel<br /> <br /> kho_fill_kimage() unconditionally populates the kimage with KHO<br /> metadata for every kexec image type. When the image is a crash kernel,<br /> this can be problematic as the crash kernel can run in a small reserved<br /> region and the KHO scratch areas can sit outside it.<br /> The crash kernel then faults during kho_memory_init() when it<br /> tries phys_to_virt() on the KHO FDT address:<br /> <br /> Unable to handle kernel paging request at virtual address xxxxxxxx<br /> ...<br /> fdt_offset_ptr+...<br /> fdt_check_node_offset_+...<br /> fdt_first_property_offset+...<br /> fdt_get_property_namelen_+...<br /> fdt_getprop+...<br /> kho_memory_init+...<br /> mm_core_init+...<br /> start_kernel+...<br /> <br /> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH<br /> images, but kho_fill_kimage() was missing the same guard. As<br /> kho_fill_kimage() is the single point that populates image-&gt;kho.fdt<br /> and image-&gt;kho.scratch, fixing it here is sufficient for both arm64<br /> and x86 as the FDT and boot_params path are bailing out when these<br /> fields are unset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sprd: fix error pointer deref after DMA setup failure<br /> <br /> The driver falls back to PIO mode if DMA setup fails during probe.<br /> <br /> Make sure to check the dma.enabled flag before trying to release the DMA<br /> channels also on late probe errors to avoid dereferencing an error<br /> pointer (or attempting to release a channel a second time).<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap<br /> <br /> Sashiko pointed out that the driver could drop PAGE_SIZE from the<br /> pgsize_bitmap. That is technically allowed but nothing does it, and<br /> such an iommu_domain would not be used with the DMA API today.<br /> <br /> Still, it is against the design and it is trivial to fix up. Lift<br /> the PT_WARN_ON to the if branch and just skip the fast path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Handle unmap error when iommu_debug is enabled<br /> <br /> Sashiko noticed a latent bug where the map error flow called iommu_unmap()<br /> which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however<br /> since this is an error path the map flow never actually established the<br /> original iommu_debug_map() it will malfunction.<br /> <br /> Lift the unmap error handling into iommu_map_nosync() and reorder it so<br /> the trace_map()/iommu_debug_map() records the partial mapping and then<br /> immediately unmaps it. This avoid creating the unbalanced tracking and<br /> provides saner tracing instead of a unmap unmatched to any map.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN<br /> <br /> Commit "iommu: return full error code from iommu_map_sg[_atomic]()"<br /> changed iommu_map_sgtable() to return an ssize_t and negative values<br /> in error cases, rather than a size_t and a zero.<br /> <br /> Store the return value in the appropriate type and in case of error,<br /> return it rather than WARNing.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/719685/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: Fix a reference leak in a6xx_gpu_init()<br /> <br /> In a6xx_gpu_init(), node is obtained via of_parse_phandle().<br /> While there was a manual of_node_put() at the end of the<br /> common path, several early error returns would bypass this call,<br /> resulting in a reference leak.<br /> Fix this by using the __free(device_node) cleanup handler to<br /> release the reference when the variable goes out of scope.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/700661/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix error path leaks in some WMI WOW calls<br /> <br /> Fix two instances where we used to directly return the result of<br /> ath11k_wmi_cmd_send(...). Because we did not check the return value, we<br /> also did not free the skb in the error path.