Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ensure that VID header offset + VID header size

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: acpi: Fix possible memory leak of ffh_ctxt<br /> <br /> Allocated &amp;#39;ffh_ctxt&amp;#39; memory leak is possible if the SMCCC version<br /> and conduit checks fail and -EOPNOTSUPP is returned without freeing the<br /> allocated memory.<br /> <br /> Fix the same by moving the allocation after the SMCCC version and<br /> conduit checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()<br /> <br /> The kfree() should be called when memory fails to be allocated for<br /> cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be<br /> a memory leak, so add kfree() to fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: fsl_mqs: move of_node_put() to the correct location<br /> <br /> of_node_put() should have been done directly after<br /> mqs_priv-&gt;regmap = syscon_node_to_regmap(gpr_np);<br /> otherwise it creates a reference leak on the success path.<br /> <br /> To fix this, of_node_put() is moved to the correct location, and change<br /> all the gotos to direct returns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: ublk: make sure that block size is set correctly<br /> <br /> block size is one very key setting for block layer, and bad block size<br /> could panic kernel easily.<br /> <br /> Make sure that block size is set correctly.<br /> <br /> Meantime if ublk_validate_params() fails, clear ub-&gt;params so that disk<br /> is prevented from being added.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix i_disksize exceeding i_size problem in paritally written case<br /> <br /> It is possible for i_disksize can exceed i_size, triggering a warning.<br /> <br /> generic_perform_write<br /> copied = iov_iter_copy_from_user_atomic(len) // copied i_disksize, newsize) // update i_disksize<br /> | generic_write_end<br /> | copied = block_write_end(copied, len) // copied = 0<br /> | if (unlikely(copied inode-&gt;i_size) // return false<br /> if (unlikely(copied == 0))<br /> goto again;<br /> if (unlikely(iov_iter_fault_in_readable(i, bytes))) {<br /> status = -EFAULT;<br /> break;<br /> }<br /> <br /> We get i_disksize greater than i_size here, which could trigger WARNING<br /> check &amp;#39;i_size_read(inode) i_disksize&amp;#39; while doing dio:<br /> <br /> ext4_dio_write_iter<br /> iomap_dio_rw<br /> __iomap_dio_rw // return err, length is not aligned to 512<br /> ext4_handle_inode_extension<br /> WARN_ON_ONCE(i_size_read(inode) i_disksize) // Oops<br /> <br /> WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319<br /> CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2<br /> RIP: 0010:ext4_file_write_iter+0xbc7<br /> Call Trace:<br /> vfs_write+0x3b1<br /> ksys_write+0x77<br /> do_syscall_64+0x39<br /> <br /> Fix it by updating &amp;#39;copied&amp;#39; value before updating i_disksize just like<br /> ext4_write_inline_data_end() does.<br /> <br /> A reproducer can be found in the buganizer link below.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()<br /> <br /> There is a memory leaks problem reported by kmemleak:<br /> <br /> unreferenced object 0xffff888102007a00 (size 128):<br /> comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)<br /> hex dump (first 32 bytes):<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> backtrace:<br /> [] __kmalloc+0x4d/0x150<br /> [] ubi_eba_create_table+0x76/0x170 [ubi]<br /> [] ubi_resize_volume+0x1be/0xbc0 [ubi]<br /> [] ubi_cdev_ioctl+0x701/0x1850 [ubi]<br /> [] __x64_sys_ioctl+0x11d/0x170<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This is due to a mismatch between create and destroy interfaces, and<br /> in detail that "new_eba_tbl" created by ubi_eba_create_table() but<br /> destroyed by kfree(), while will causing "new_eba_tbl-&gt;entries" not<br /> freed.<br /> <br /> Fix it by replacing kfree(new_eba_tbl) with<br /> ubi_eba_destroy_table(new_eba_tbl)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create<br /> <br /> We can&amp;#39;t simply free the connector after calling drm_connector_init on it.<br /> We need to clean up the drm side first.<br /> <br /> It might not fix all regressions from commit 2b5d1c29f6c4<br /> ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),<br /> but at least it fixes a memory corruption in error handling related to<br /> that commit.

*** Pendiente de traducción *** Click Studios Passwordstate before 9.9 Build 9972 has a potential authentication bypass for Passwordstate emergency access. By using a crafted URL while on the Emergency Access web page, an unauthorized person can gain access to the Passwordstate Administration section.

*** Pendiente de traducción *** The The Events Calendar plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 6.15.2 via the REST endpoint. This makes it possible for unauthenticated attackers to extract information about password-protected vendors or venues.

*** Pendiente de traducción *** The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 017700000001 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415.

*** Pendiente de traducción *** The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 0 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415. NOTE: in current versions of several applications, connection attempts to the IP address 0 (interpreted as 0.0.0.0) are blocked with error messages such as net::ERR_ADDRESS_INVALID. However, in some situations that depend on both application version and operating system, connection attempts to 0 and 0.0.0.0 are considered connection attempts to 127.0.0.1 (and, for this reason, a false value of isPublic would be preferable).