Vulnerabilidades

*** Pendiente de traducción *** The Sell BTC - Cryptocurrency Selling Calculator plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'orderform_data' AJAX action in all versions up to, and including, 1.5 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in order records that will execute whenever an administrator accesses the Orders page in the admin dashboard. The vulnerability was partially patched in version 1.5.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: etas_es58x: allow partial RX URB allocation to succeed<br /> <br /> When es58x_alloc_rx_urbs() fails to allocate the requested number of<br /> URBs but succeeds in allocating some, it returns an error code.<br /> This causes es58x_open() to return early, skipping the cleanup label<br /> &amp;#39;free_urbs&amp;#39;, which leads to the anchored URBs being leaked.<br /> <br /> As pointed out by maintainer Vincent Mailhol, the driver is designed<br /> to handle partial URB allocation gracefully. Therefore, partial<br /> allocation should not be treated as a fatal error.<br /> <br /> Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been<br /> allocated, restoring the intended behavior and preventing the leak<br /> in es58x_open().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()<br /> <br /> In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,<br /> the function jumps to the out_scratch label without freeing the already<br /> allocated dsaddrs list, leading to a memory leak.<br /> <br /> Fix this by jumping to the out_err_drain_dsaddrs label, which properly<br /> frees the dsaddrs list before cleaning up other resources.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gud: fix NULL fb and crtc dereferences on USB disconnect<br /> <br /> On disconnect drm_atomic_helper_disable_all() is called which<br /> sets both the fb and crtc for a plane to NULL before invoking a commit.<br /> <br /> This causes a kernel oops on every display disconnect.<br /> <br /> Add guards for those dereferences.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_pch_pic_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_pch_pic_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_ipi_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_ipi_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_eiointc_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_eiointc_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()<br /> <br /> The for_each_available_child_of_node() calls of_node_put() to<br /> release child_np in each success loop. After breaking from the<br /> loop with the child_np has been released, the code will jump to<br /> the put_child label and will call the of_node_put() again if the<br /> devm_request_threaded_irq() fails. These cause a double free bug.<br /> <br /> Fix by returning directly to avoid the duplicate of_node_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak<br /> <br /> In gs_can_open(), the URBs for USB-in transfers are allocated, added to the<br /> parent-&gt;rx_submitted anchor and submitted. In the complete callback<br /> gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In<br /> gs_can_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(parent-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in gs_can_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> gs_usb_receive_bulk_callback() to the parent-&gt;rx_submitted anchor.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix kmemleak by releasing references to fault configfs items<br /> <br /> When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk<br /> driver sets up fault injection support by creating the timeout_inject,<br /> requeue_inject, and init_hctx_fault_inject configfs items as children<br /> of the top-level nullbX configfs group.<br /> <br /> However, when the nullbX device is removed, the references taken to<br /> these fault-config configfs items are not released. As a result,<br /> kmemleak reports a memory leak, for example:<br /> <br /> unreferenced object 0xc00000021ff25c40 (size 32):<br /> comm "mkdir", pid 10665, jiffies 4322121578<br /> hex dump (first 32 bytes):<br /> 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_<br /> 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject..........<br /> backtrace (crc 1a018c86):<br /> __kmalloc_node_track_caller_noprof+0x494/0xbd8<br /> kvasprintf+0x74/0xf4<br /> config_item_set_name+0xf0/0x104<br /> config_group_init_type_name+0x48/0xfc<br /> fault_config_init+0x48/0xf0<br /> 0xc0080000180559e4<br /> configfs_mkdir+0x304/0x814<br /> vfs_mkdir+0x49c/0x604<br /> do_mkdirat+0x314/0x3d0<br /> sys_mkdir+0xa0/0xd8<br /> system_call_exception+0x1b0/0x4f0<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Fix this by explicitly releasing the references to the fault-config<br /> configfs items when dropping the reference to the top-level nullbX<br /> configfs group.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: omap-dma: fix dma_pool resource leak in error paths<br /> <br /> The dma_pool created by dma_pool_create() is not destroyed when<br /> dma_async_device_register() or of_dma_controller_register() fails,<br /> causing a resource leak in the probe error paths.<br /> <br /> Add dma_pool_destroy() in both error paths to properly release the<br /> allocated dma_pool resource.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/userq: Fix fence reference leak on queue teardown v2<br /> <br /> The user mode queue keeps a pointer to the most recent fence in<br /> userq-&gt;last_fence. This pointer holds an extra dma_fence reference.<br /> <br /> When the queue is destroyed, we free the fence driver and its xarray,<br /> but we forgot to drop the last_fence reference.<br /> <br /> Because of the missing dma_fence_put(), the last fence object can stay<br /> alive when the driver unloads. This leaves an allocated object in the<br /> amdgpu_userq_fence slab cache and triggers<br /> <br /> This is visible during driver unload as:<br /> <br /> BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()<br /> kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects<br /> Call Trace:<br /> kmem_cache_destroy<br /> amdgpu_userq_fence_slab_fini<br /> amdgpu_exit<br /> __do_sys_delete_module<br /> <br /> Fix this by putting userq-&gt;last_fence and clearing the pointer during<br /> amdgpu_userq_fence_driver_free().<br /> <br /> This makes sure the fence reference is released and the slab cache is<br /> empty when the module exits.<br /> <br /> v2: Update to only release userq-&gt;last_fence with dma_fence_put()<br /> (Christian)<br /> <br /> (cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)