Vulnerabilities

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.

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)

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.

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.

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.

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.

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

The issue was addressed with improved checks. This issue is fixed in Xcode 26. Processing an overly large path value may crash a process.

An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Tahoe 26. An app may be able to disclose coprocessor memory.

This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Tahoe 26. An app may be able to access protected user data.

A path handling issue was addressed with improved validation. This issue is fixed in Xcode 26. Processing an overly large path value may crash a process.

This issue was addressed with improved checks. This issue is fixed in Xcode 26. An app may be able to break out of its sandbox.