Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions<br /> <br /> sdca_dev_unregister_functions() iterates over all SDCA function<br /> descriptors and calls sdca_dev_unregister() on each func_dev without<br /> checking for NULL. When a function registration has failed partway<br /> through, or the device cleanup races with probe deferral, func_dev<br /> entries may be NULL, leading to a kernel oops:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> RIP: 0010:device_del+0x1e/0x3e0<br /> Call Trace:<br /> sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca]<br /> release_nodes+0x35/0xb0<br /> devres_release_all+0x90/0x100<br /> device_unbind_cleanup+0xe/0x80<br /> device_release_driver_internal+0x1c1/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x161/0x3e0<br /> device_unregister+0x17/0x60<br /> sdw_delete_slave+0xb6/0xd0 [soundwire_bus]<br /> sdw_bus_master_delete+0x1e/0x50 [soundwire_bus]<br /> ...<br /> sof_probe_work+0x19/0x30 [snd_sof]<br /> <br /> This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake)<br /> with the SOF audio driver probe failing due to missing Panther Lake<br /> firmware, causing the subsequent cleanup of SoundWire devices to<br /> trigger the crash.<br /> <br /> Fix this with three changes:<br /> <br /> 1) Add a NULL guard in sdca_dev_unregister() so that callers do not<br /> need to pre-validate the pointer (defense in depth).<br /> <br /> 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries<br /> and clear func_dev to NULL after unregistration, making the<br /> function idempotent and safe against double-invocation.<br /> <br /> 3) In sdca_dev_register_functions(), roll back all previously<br /> registered functions when a later one fails, so the function<br /> array is never left in a partially-populated state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Fix driver removal with disabled KMS<br /> <br /> DRM atomic and modesetting aren&amp;#39;t initialized if virtio-gpu driver built<br /> with disabled KMS, leading to access of uninitialized data on driver<br /> removal/unbinding and crashing kernel. Fix it by skipping shutting down<br /> atomic core with unavailable KMS.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES<br /> <br /> Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the<br /> uwtable annotation for functions, but not for the module. This means<br /> that compiler-generated functions such as &amp;#39;asan.module_ctor&amp;#39; do not<br /> receive the uwtable annotation.<br /> <br /> When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot<br /> failures because the dwarf information emitted for the kasan<br /> constructors is wrong, which causes the SCS boot patching code to<br /> patch the constructor in an illegal manner. Specifically, the paciasp<br /> instruction is patched, but the autiasp instruction is not. This<br /> mismatch leads to a crash when the constructor is called during boot.<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90<br /> Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1<br /> <br /> Specifically the faulting instruction is the (*fn)() to invoke the<br /> constructor in do_ctors() of the init/main.c file.<br /> <br /> Once the fix lands in rustc, this flag can be made conditional on the<br /> rustc version. Note that passing the flag on a rustc with the fix<br /> present has no effect.<br /> <br /> [ The fix [1] has landed for Rust 1.98.0 (expected release on<br /> 2026-08-20).<br /> <br /> Thus add a version check as discussed.<br /> <br /> - Miguel ]<br /> <br /> [ Adjusted link and comment. - Miguel ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t WARN if memory is dirtied without a vCPU when the VM is dying<br /> <br /> When marking a page dirty, complain about not having a running/loaded vCPU<br /> if and only if the VM is still alive, i.e. its refcount is non-zero. This<br /> will allow fixing a memory leak for x86 SEV-ES guests without hitting what<br /> is effectively a false positive on the WARN.<br /> <br /> For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page<br /> across an exit to userspace, and typically unmaps the page on the next<br /> KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM<br /> needs to unmap the page when the vCPU is destroyed, which in turn triggers<br /> the WARN about not having a running vCPU.<br /> <br /> Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,<br /> as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;<br /> suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But<br /> loading a vCPU during destruction is gross (ideally nVMX code would be<br /> cleaned up), risks complicating the SEV-ES code (KVM would need to ensure<br /> the temporarily load()+put() only runs when the vCPU isn&amp;#39;t already loaded),<br /> and is ultimately pointless.<br /> <br /> The motivation for the WARN is to guard against KVM dirtying guest memory<br /> without pushing the corresponding GFN to the active vCPU&amp;#39;s dirty ring, e.g.<br /> to ensure userspace doesn&amp;#39;t miss a dirty page. But for the VM&amp;#39;s refcount<br /> to reach zero, there can&amp;#39;t be _any_ userspace mappings to the dirty ring,<br /> as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if<br /> userspace had a valid mapping for the dirty ring, then the vCPU file and<br /> thus the owning VM would still be alive. And so since userspace can&amp;#39;t<br /> possibly reach the dirty ring, whether or not KVM technically "misses" a<br /> push to the dirty ring is irrelevant.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mcp23s08: Initialize mcp-&gt;dev and mcp-&gt;addr before regmap init<br /> <br /> Regmap initialization triggers regcache_maple_populate() which attempts<br /> SPI read to populate cache. SPI read requires mcp-&gt;dev and mcp-&gt;addr to<br /> be set, without them, NULL pointer dereference occurs during probe.<br /> <br /> Move initialization before mcp23s08_spi_regmap_init() call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow<br /> <br /> Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from<br /> VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in<br /> __switch_to(). The read uses ldr, but the KASAN shadow address is<br /> byte-granular and is not guaranteed to be word aligned.<br /> <br /> ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and<br /> CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()<br /> with an alignment exception before reaching init.<br /> <br /> Use ldrb for the dummy shadow access. The code only needs to fault in the<br /> shadow mapping if the stack shadow is missing, so a byte load is sufficient<br /> and matches the granularity of KASAN shadow memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: call pagetable dtor when freeing hot-removed page tables<br /> <br /> Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in<br /> __create_pgd_mapping()") page-table allocation on ARM64 always calls<br /> pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to<br /> PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However<br /> the matching pagetable_dtor() calls were never added.<br /> <br /> With DEBUG_VM enabled on kernel versions prior to v6.17 without<br /> 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type")<br /> this leads to the following warning when freeing these pages due to<br /> page-&gt;page_type sharing page-&gt;_mapcount:<br /> <br /> BUG: Bad page state in process ... pfn:284fbb<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb<br /> flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)<br /> page_type: f2(table)<br /> page dumped because: nonzero mapcount<br /> Call trace:<br /> bad_page+0x13c/0x160<br /> __free_frozen_pages+0x6cc/0x860<br /> ___free_pages+0xf4/0x180<br /> free_pages+0x54/0x80<br /> free_hotplug_page_range.part.0+0x58/0x90<br /> free_empty_tables+0x438/0x500<br /> __remove_pgd_mapping.constprop.0+0x60/0xa8<br /> arch_remove_memory+0x48/0x80<br /> try_remove_memory+0x158/0x1d8<br /> offline_and_remove_memory+0x138/0x180<br /> <br /> It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is<br /> defined and incorrect NR_PAGETABLE stats. Fix this by calling<br /> pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page<br /> to undo the effects of calling pagetable_*_ctor().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fhandle: fix UAF due to unlocked -&gt;mnt_ns read in may_decode_fh()<br /> <br /> may_decode_fh() accesses mount::mnt_ns without holding any locks; that<br /> means the mount can concurrently be unmounted, and the mnt_namespace can<br /> concurrently be freed after an RCU grace period.<br /> <br /> This race can happens as follows, assuming that the mount point was<br /> created by open_tree(..., OPEN_TREE_CLONE):<br /> <br /> thread 1 thread 2 RCU<br /> __do_sys_open_by_handle_at<br /> do_handle_open<br /> handle_to_path<br /> may_decode_fh<br /> is_mounted<br /> [mount::mnt_ns access]<br /> [mount::mnt_ns access]<br /> __do_sys_close<br /> fput_close_sync<br /> __fput<br /> dissolve_on_fput<br /> umount_tree<br /> class_namespace_excl_destructor<br /> namespace_unlock<br /> free_mnt_ns<br /> mnt_ns_tree_remove<br /> call_rcu(mnt_ns_release_rcu)<br /> mnt_ns_release_rcu<br /> mnt_ns_release<br /> kfree<br /> [mnt_namespace::user_ns access] **UAF**<br /> <br /> Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like<br /> in __prepend_path().<br /> Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()<br /> for writers that can race with lockless readers.<br /> <br /> This bug is unreachable unless one of the following is set:<br /> <br /> - CONFIG_PREEMPTION<br /> - CONFIG_RCU_STRICT_GRACE_PERIOD<br /> <br /> because it requires an RCU grace period to happen during a syscall without<br /> an explicit preemption.<br /> <br /> This doesn&amp;#39;t seem to have interesting security impact; worst-case, it could<br /> leak the result of an integer comparison to userspace (from the level<br /> check in cap_capable()), cause an endless loop, or crash the kernel by<br /> dereferencing an invalid address.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix clock and pinctrl state inconsistency in runtime PM<br /> <br /> In i2c_imx_runtime_suspend(), the clock is disabled before switching<br /> the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails,<br /> the runtime suspend is aborted but the clock remains disabled, causing<br /> a system crash when the hardware is subsequently accessed.<br /> <br /> Fix this by switching the pinctrl state before disabling the clock so<br /> that a pinctrl failure leaves the clock enabled and the hardware<br /> accessible.<br /> <br /> In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep<br /> if clk_enable() fails to keep the consistent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()<br /> <br /> On all modern platforms Qualcomm CCI controller provides two I2C masters,<br /> and on particular boards only one I2C master may be initialized, and in<br /> such cases the device unbinding or driver removal causes a NULL pointer<br /> dereference, because cci_halt() is called for all two I2C masters, but<br /> a completion is initialized only for the single enabled master:<br /> <br /> % rmmod i2c-qcom-cci<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> <br /> Call trace:<br /> __wait_for_common+0x194/0x1a8 (P)<br /> wait_for_completion_timeout+0x20/0x2c<br /> cci_remove+0xc4/0x138 [i2c_qcom_cci]<br /> platform_remove+0x20/0x30<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1c8/0x224<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci]<br /> ....

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()<br /> <br /> of_reserved_mem_lookup() may return NULL if the reserved memory region<br /> referenced by the "memory-region" phandle is not found in the reserved<br /> memory table (e.g. due to a misconfigured DTS or a removed<br /> memory-region node). The current code dereferences the returned<br /> pointer without checking for NULL, leading to a kernel NULL pointer<br /> dereference at the following lines:<br /> <br /> dma_addr = rmem-&gt;base; // line 1156<br /> num_desc = div_u64(rmem-&gt;size, buf_size); // line 1160<br /> <br /> Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if<br /> the lookup fails, which is consistent with the existing error handling<br /> for of_parse_phandle() failure in the same code block.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix NULL pointer dereference in bond_do_ioctl()<br /> <br /> In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which<br /> can return NULL if the requested interface name does not exist. However,<br /> the subsequent slave_dbg() call is placed before the NULL check:<br /> <br /> slave_dev = __dev_get_by_name(net, ifr-&gt;ifr_slave);<br /> slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here<br /> if (!slave_dev)<br /> return -ENODEV;<br /> <br /> The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt,<br /> (slave_dev)-&gt;name, ...) which unconditionally dereferences slave_dev-&gt;name<br /> before the NULL check is performed. This results in a NULL pointer<br /> dereference kernel oops when a user calls bonding ioctl (e.g.<br /> SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave<br /> interface name.<br /> <br /> This is reachable from userspace via the bonding ioctl interface with<br /> CAP_NET_ADMIN capability, making it a potential local denial-of-service<br /> vector.<br /> <br /> Fix by moving the slave_dbg() call after the NULL check.