Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue<br /> <br /> System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up<br /> gets called for uninitialized wait queue sp-&gt;nvme_ls_waitq.<br /> <br /> qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0<br /> qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11<br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021<br /> Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]<br /> RIP: 0010:__wake_up_common+0x4c/0x190<br /> RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086<br /> RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8<br /> R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20<br /> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> __wake_up_common_lock+0x7c/0xc0<br /> qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]<br /> ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]<br /> ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]<br /> ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]<br /> <br /> Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed<br /> previously in the commits tagged Fixed: below.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe<br /> <br /> Use devm_of_iomap() instead of of_iomap() to automatically<br /> handle the unused ioremap region. If any error occurs, regions allocated by<br /> kzalloc() will leak, but using devm_kzalloc() instead will automatically<br /> free the memory using devm_kfree().<br /> <br /> Also, fix error handling of hws by adding unregister_hws label, which<br /> unregisters remaining hws when iomap failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ensure that VID header offset + VID header size

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.

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.

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.

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.

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.