Vulnerabilities

The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxDeleteCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete categories.

The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxRenameCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to rename categories.

The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxClearCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to clear categories.

A flaw in the Windows Installer in Thales SafeNet Authentication Client prior to 10.8 R10 on Windows allows an attacker to escalate their privilege level via local access.

A flaw in Thales SafeNet Authentication Client prior to 10.8 R10 on Windows allows an attacker to execute code at a SYSTEM level via local access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix use-after-free in tw_timer_handler<br /> <br /> A real world panic issue was found as follow in Linux 5.4.<br /> <br /> BUG: unable to handle page fault for address: ffffde49a863de28<br /> PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0<br /> RIP: 0010:tw_timer_handler+0x20/0x40<br /> Call Trace:<br /> <br /> call_timer_fn+0x2b/0x120<br /> run_timer_softirq+0x1ef/0x450<br /> __do_softirq+0x10d/0x2b8<br /> irq_exit+0xc7/0xd0<br /> smp_apic_timer_interrupt+0x68/0x120<br /> apic_timer_interrupt+0xf/0x20<br /> <br /> This issue was also reported since 2017 in the thread [1],<br /> unfortunately, the issue was still can be reproduced after fixing<br /> DCCP.<br /> <br /> The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net<br /> namespace is destroyed since tcp_sk_ops is registered befrore<br /> ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops<br /> in the list of pernet_list. There will be a use-after-free on<br /> net-&gt;mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net<br /> if there are some inflight time-wait timers.<br /> <br /> This bug is not introduced by commit f2bf415cfed7 ("mib: add net to<br /> NET_ADD_STATS_BH") since the net_statistics is a global variable<br /> instead of dynamic allocation and freeing. Actually, commit<br /> 61a7e26028b9 ("mib: put net statistics on struct net") introduces<br /> the bug since it put net statistics on struct net and free it when<br /> net namespace is destroyed.<br /> <br /> Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug<br /> and replace pr_crit() with panic() since continuing is meaningless<br /> when init_ipv4_mibs() fails.<br /> <br /> [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/dbgfs: fix &amp;#39;struct pid&amp;#39; leaks in &amp;#39;dbgfs_target_ids_write()&amp;#39;<br /> <br /> DAMON debugfs interface increases the reference counts of &amp;#39;struct pid&amp;#39;s<br /> for targets from the &amp;#39;target_ids&amp;#39; file write callback<br /> (&amp;#39;dbgfs_target_ids_write()&amp;#39;), but decreases the counts only in DAMON<br /> monitoring termination callback (&amp;#39;dbgfs_before_terminate()&amp;#39;).<br /> <br /> Therefore, when &amp;#39;target_ids&amp;#39; file is repeatedly written without DAMON<br /> monitoring start/termination, the reference count is not decreased and<br /> therefore memory for the &amp;#39;struct pid&amp;#39; cannot be freed. This commit<br /> fixes this issue by decreasing the reference counts when &amp;#39;target_ids&amp;#39; is<br /> written.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: Fix TPM reservation for seal/unseal<br /> <br /> The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal<br /> and unseal operations") was correct on the mailing list:<br /> <br /> https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/<br /> <br /> But somehow got rebased so that the tpm_try_get_ops() in<br /> tpm2_seal_trusted() got lost. This causes an imbalanced put of the<br /> TPM ops and causes oopses on TIS based hardware.<br /> <br /> This fix puts back the lost tpm_try_get_ops()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/mount_setattr: always cleanup mount_kattr<br /> <br /> Make sure that finish_mount_kattr() is called after mount_kattr was<br /> succesfully built in both the success and failure case to prevent<br /> leaking any references we took when we built it. We returned early if<br /> path lookup failed thereby risking to leak an additional reference we<br /> took when building mount_kattr when an idmapped mount was requested.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: st21nfca: Fix memory leak in device probe and remove<br /> <br /> &amp;#39;phy-&gt;pending_skb&amp;#39; is alloced when device probe, but forgot to free<br /> in the error handling path and remove path, this cause memory leak<br /> as follows:<br /> <br /> unreferenced object 0xffff88800bc06800 (size 512):<br /> comm "8", pid 11775, jiffies 4295159829 (age 9.032s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x1ed/0x450<br /> [] kmalloc_reserve+0x37/0xd0<br /> [] __alloc_skb+0x124/0x380<br /> [] st21nfca_hci_i2c_probe+0x170/0x8f2<br /> <br /> Fix it by freeing &amp;#39;pending_skb&amp;#39; in error and remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix kernel panic caused by race of smc_sock<br /> <br /> A crash occurs when smc_cdc_tx_handler() tries to access smc_sock<br /> but smc_release() has already freed it.<br /> <br /> [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88<br /> [ 4570.696048] #PF: supervisor write access in kernel mode<br /> [ 4570.696728] #PF: error_code(0x0002) - not-present page<br /> [ 4570.697401] PGD 0 P4D 0<br /> [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111<br /> [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0<br /> [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30<br /> <br /> [ 4570.711446] Call Trace:<br /> [ 4570.711746] <br /> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0<br /> [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560<br /> [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10<br /> [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140<br /> [ 4570.714083] __do_softirq+0x123/0x2f4<br /> [ 4570.714521] irq_exit_rcu+0xc4/0xf0<br /> [ 4570.714934] common_interrupt+0xba/0xe0<br /> <br /> Though smc_cdc_tx_handler() checked the existence of smc connection,<br /> smc_release() may have already dismissed and released the smc socket<br /> before smc_cdc_tx_handler() further visits it.<br /> <br /> smc_cdc_tx_handler() |smc_release()<br /> if (!conn) |<br /> |<br /> |smc_cdc_tx_dismiss_slots()<br /> | smc_cdc_tx_dismisser()<br /> |<br /> |sock_put(&amp;smc-&gt;sk) sk) (panic) |<br /> <br /> To make sure we won&amp;#39;t receive any CDC messages after we free the<br /> smc_sock, add a refcount on the smc_connection for inflight CDC<br /> message(posted to the QP but haven&amp;#39;t received related CQE), and<br /> don&amp;#39;t release the smc_connection until all the inflight CDC messages<br /> haven been done, for both success or failed ones.<br /> <br /> Using refcount on CDC messages brings another problem: when the link<br /> is going to be destroyed, smcr_link_clear() will reset the QP, which<br /> then remove all the pending CQEs related to the QP in the CQ. To make<br /> sure all the CQEs will always come back so the refcount on the<br /> smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced<br /> by smc_ib_modify_qp_error().<br /> And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we<br /> need to wait for all pending WQEs done, or we may encounter use-after-<br /> free when handling CQEs.<br /> <br /> For IB device removal routine, we need to wait for all the QPs on that<br /> device been destroyed before we can destroy CQs on the device, or<br /> the refcount on smc_connection won&amp;#39;t reach 0 and smc_sock cannot be<br /> released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: intel-sdw-acpi: harden detection of controller<br /> <br /> The existing code currently sets a pointer to an ACPI handle before<br /> checking that it&amp;#39;s actually a SoundWire controller. This can lead to<br /> issues where the graph walk continues and eventually fails, but the<br /> pointer was set already.<br /> <br /> This patch changes the logic so that the information provided to<br /> the caller is set when a controller is found.