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 /> 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 /> 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 /> mm/mincore: handle non-swap entries before !CONFIG_SWAP guard<br /> <br /> mincore_swap() also fields migration/hwpoison entries (and shmem<br /> swapin-error entries), which can exist on !CONFIG_SWAP builds when<br /> CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The<br /> !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return,<br /> so mincore_pte_range() can spuriously WARN and report these pages<br /> nonresident on !CONFIG_SWAP kernels.<br /> <br /> Move the guard below the non-swap-entry check so only true swap entries<br /> trip the WARN, and migration/hwpoison entries take the existing "uptodate<br /> / non-shmem" path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/reclaim: handle ctx allocation failure<br /> <br /> Patch series "mm/damon/{reclaim,lru_sort}: handle ctx allocation failures".<br /> <br /> DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their<br /> damon_ctx object allocations fail. The bugs are expected to happen<br /> infrequently because the allocations are arguably too small to fail on<br /> common setups. But theoretically they are possible and the consequences<br /> are bad. Fix those.<br /> <br /> The issues were discovered [1] by Sashiko.<br /> <br /> <br /> This patch (of 2):<br /> <br /> DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init<br /> function. damon_reclaim_enabled_store() wrongly assumes the allocation<br /> will always succeed once tried. If the damon_ctx allocation was failed,<br /> therefore, code execution reaches to damon_commit_ctx() while &amp;#39;ctx&amp;#39; is<br /> NULL. As a result, it dereferences the NULL &amp;#39;ctx&amp;#39; pointer. Avoid the<br /> NULL dereference by returning -ENOMEM if &amp;#39;ctx&amp;#39; is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: handle ctx allocation failure<br /> <br /> DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init<br /> function. damon_lru_sort_enabled_store() wrongly assumes the allocation<br /> will always succeed once tried. If the damon_ctx allocation was failed,<br /> therefore, code execution reaches to damon_commit_ctx() while &amp;#39;ctx&amp;#39; is<br /> NULL. As a result, it dereferences the NULL &amp;#39;ctx&amp;#39; pointer. Avoid the<br /> NULL dereference by returning -ENOMEM if &amp;#39;ctx&amp;#39; is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: layouts: onie-tlv: fix hang on unknown types<br /> <br /> The EEPROM on my board has a vendor specific entry of type 0x41. When<br /> stumbling upon that, this driver hangs in an endless loop.<br /> <br /> Fix it by keep incrementing the offset on unknown entries, so the loop<br /> will eventually stop.

*** 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.

*** 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 /> 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 /> slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd<br /> <br /> When the remoteproc starts in parallel with the NGD driver being probed,<br /> or the remoteproc is already up when the PDR lookup is being registered,<br /> or in the theoretical event that we get an interrupt from the hardware,<br /> these callbacks will operate on uninitialized data. This result in<br /> issues to boot the affected boards.<br /> <br /> One such example can be seen in the following fault, where<br /> qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work.<br /> <br /> [ 21.858578] ------------[ cut here ]------------<br /> [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116<br /> ...<br /> [ 21.859251] Call trace:<br /> [ 21.859255] __queue_work+0x5e0/0x790 (P)<br /> [ 21.859265] queue_work_on+0x6c/0xf0<br /> [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl]<br /> [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl]<br /> [ 21.859318] notifier_call_chain+0xa4/0x230<br /> [ 21.859329] srcu_notifier_call_chain+0x64/0xb8<br /> [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common]<br /> [ 21.859355] rproc_start+0x130/0x230<br /> [ 21.859367] rproc_boot+0x3d4/0x518<br /> ...<br /> <br /> Move the enablement of interrupts, and the registration of SSR and PDR<br /> until after the NGD device has been registered.<br /> <br /> This could be further refined by moving initialization to the control<br /> driver probe and by removing the platform driver model from the picture.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Don&amp;#39;t warn on NULL cgrp_moving_from in scx_cgroup_move_task()<br /> <br /> A WARN fires when systemd&amp;#39;s user manager writes "+cpu +memory +pids" to<br /> its own subtree_control while a sched_ext scheduler is loaded:<br /> <br /> WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0<br /> scx_cgroup_move_task+0xa8/0xb0<br /> sched_move_task+0x134/0x290<br /> cpu_cgroup_attach+0x39/0x70<br /> cgroup_migrate_execute+0x37d/0x450<br /> cgroup_update_dfl_csses+0x1e3/0x270<br /> cgroup_subtree_control_write+0x3e7/0x440<br /> <br /> scx_cgroup_can_attach() arms cgrp_moving_from only when a task&amp;#39;s cpu<br /> cgroup changes. It can still be NULL when scx_cgroup_move_task() runs,<br /> through this sequence:<br /> <br /> Step Result<br /> --------------------------------- ----------------------------------<br /> 1. cpu enabled on cgroup G cpu css = A<br /> 2. cpu toggled off then on for G A killed, B created (same cgroup)<br /> 3. an exiting task keeps A alive migration skips it, A now stale<br /> 4. +memory migrates G stale A vs current B pulls cpu in<br /> 5. cpu attach runs for all tasks hits a live, cpu-unchanged task<br /> 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -&gt; WARN<br /> <br /> The mismatch is that scx_cgroup_can_attach() keys on cgroup identity<br /> while migration drives the move on css identity, so a NULL cgrp_moving_from<br /> here is a legitimate css-only migration, not a missing prep.<br /> <br /> The call is already gated on cgrp_moving_from, so just drop the warning.<br /> ops.cgroup_prep_move() and ops.cgroup_move() stay paired.