Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Add alignment check for event ring read pointer<br /> <br /> Though we do check the event ring read pointer by "is_valid_ring_ptr"<br /> to make sure it is in the buffer range, but there is another risk the<br /> pointer may be not aligned. Since we are expecting event ring elements<br /> are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer<br /> could lead to multiple issues like DoS or ring buffer memory corruption.<br /> <br /> So add a alignment check for event ring read pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pmic_glink_altmode: fix port sanity check<br /> <br /> The PMIC GLINK altmode driver currently supports at most two ports.<br /> <br /> Fix the incomplete port sanity check on notifications to avoid<br /> accessing and corrupting memory beyond the port array if we ever get a<br /> notification for an unsupported port.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: sleep: Fix possible deadlocks in core system-wide PM code<br /> <br /> It is reported that in low-memory situations the system-wide resume core<br /> code deadlocks, because async_schedule_dev() executes its argument<br /> function synchronously if it cannot allocate memory (and not only in<br /> that case) and that function attempts to acquire a mutex that is already<br /> held. Executing the argument function synchronously from within<br /> dpm_async_fn() may also be problematic for ordering reasons (it may<br /> cause a consumer device&amp;#39;s resume callback to be invoked before a<br /> requisite supplier device&amp;#39;s one, for example).<br /> <br /> Address this by changing the code in question to use<br /> async_schedule_dev_nocall() for scheduling the asynchronous<br /> execution of device suspend and resume functions and to directly<br /> run them synchronously if async_schedule_dev_nocall() returns false.

The Seriously Simple Podcasting WordPress plugin before 3.0.0 discloses the Podcast owner&amp;#39;s email address (which by default is the admin email address) via an unauthenticated crafted request.

The Login as User or Customer WordPress plugin through 3.8 does not prevent users to log in as any other user on the site.

The Enhanced Text Widget WordPress plugin before 1.6.6 does not validate and escape some of its Widget options before outputting them back in attributes, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

The Ultimate Posts Widget WordPress plugin before 2.3.1 does not validate and escape some of its Widget options before outputting them back in attributes, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

The 404 Solution WordPress plugin before 2.35.8 does not properly sanitise and escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by high privilege users such as admins.

The Starbox WordPress plugin before 3.5.0 does not sanitise and escape some parameters, which could allow users with a role as low as Contributor to perform Cross-Site Scripting attacks

The Paid Memberships Pro WordPress plugin before 2.12.9 does not prevent user with at least the contributor role from leaking other users&amp;#39; sensitive metadata.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Don&amp;#39;t unref the same fb many times by mistake due to deadlock handling<br /> <br /> If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()<br /> we proceed to unref the fb and then retry the whole thing from the top.<br /> But we forget to reset the fb pointer back to NULL, and so if we then<br /> get another error during the retry, before the fb lookup, we proceed<br /> the unref the same fb again without having gotten another reference.<br /> The end result is that the fb will (eventually) end up being freed<br /> while it&amp;#39;s still in use.<br /> <br /> Reset fb to NULL once we&amp;#39;ve unreffed it to avoid doing it again<br /> until we&amp;#39;ve done another fb lookup.<br /> <br /> This turned out to be pretty easy to hit on a DG2 when doing async<br /> flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I<br /> saw that drm_closefb() simply got stuck in a busy loop while walking<br /> the framebuffer list. Fortunately I was able to convince it to oops<br /> instead, and from there it was easier to track down the culprit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix peer flow lists handling<br /> <br /> The cited change refactored mlx5e_tc_del_fdb_peer_flow() to only clear DUP<br /> flag when list of peer flows has become empty. However, if any concurrent<br /> user holds a reference to a peer flow (for example, the neighbor update<br /> workqueue task is updating peer flow&amp;#39;s parent encap entry concurrently),<br /> then the flow will not be removed from the peer list and, consecutively,<br /> DUP flag will remain set. Since mlx5e_tc_del_fdb_peers_flow() calls<br /> mlx5e_tc_del_fdb_peer_flow() for every possible peer index the algorithm<br /> will try to remove the flow from eswitch instances that it has never peered<br /> with causing either NULL pointer dereference when trying to remove the flow<br /> peer list head of peer_index that was never initialized or a warning if the<br /> list debug config is enabled[0].<br /> <br /> Fix the issue by always removing the peer flow from the list even when not<br /> releasing the last reference to it.<br /> <br /> [0]:<br /> <br /> [ 3102.985806] ------------[ cut here ]------------<br /> [ 3102.986223] list_del corruption, ffff888139110698-&gt;next is NULL<br /> [ 3102.986757] WARNING: CPU: 2 PID: 22109 at lib/list_debug.c:53 __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3102.987561] Modules linked in: act_ct nf_flow_table bonding act_tunnel_key act_mirred act_skbedit vxlan cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa openvswitch nsh xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcg<br /> ss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core [last unloaded: bonding]<br /> [ 3102.991113] CPU: 2 PID: 22109 Comm: revalidator28 Not tainted 6.6.0-rc6+ #3<br /> [ 3102.991695] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 3102.992605] RIP: 0010:__list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3102.993122] Code: 39 c2 74 56 48 8b 32 48 39 fe 75 62 48 8b 51 08 48 39 f2 75 73 b8 01 00 00 00 c3 48 89 fe 48 c7 c7 48 fd 0a 82 e8 41 0b ad ff 0b 31 c0 c3 48 89 fe 48 c7 c7 70 fd 0a 82 e8 2d 0b ad ff 0f 0b<br /> [ 3102.994615] RSP: 0018:ffff8881383e7710 EFLAGS: 00010286<br /> [ 3102.995078] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ 3102.995670] RDX: 0000000000000001 RSI: ffff88885f89b640 RDI: ffff88885f89b640<br /> [ 3102.997188] DEL flow 00000000be367878 on port 0<br /> [ 3102.998594] RBP: dead000000000122 R08: 0000000000000000 R09: c0000000ffffdfff<br /> [ 3102.999604] R10: 0000000000000008 R11: ffff8881383e7598 R12: dead000000000100<br /> [ 3103.000198] R13: 0000000000000002 R14: ffff888139110000 R15: ffff888101901240<br /> [ 3103.000790] FS: 00007f424cde4700(0000) GS:ffff88885f880000(0000) knlGS:0000000000000000<br /> [ 3103.001486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3103.001986] CR2: 00007fd42e8dcb70 CR3: 000000011e68a003 CR4: 0000000000370ea0<br /> [ 3103.002596] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 3103.003190] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 3103.003787] Call Trace:<br /> [ 3103.004055] <br /> [ 3103.004297] ? __warn+0x7d/0x130<br /> [ 3103.004623] ? __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3103.005094] ? report_bug+0xf1/0x1c0<br /> [ 3103.005439] ? console_unlock+0x4a/0xd0<br /> [ 3103.005806] ? handle_bug+0x3f/0x70<br /> [ 3103.006149] ? exc_invalid_op+0x13/0x60<br /> [ 3103.006531] ? asm_exc_invalid_op+0x16/0x20<br /> [ 3103.007430] ? __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3103.007910] mlx5e_tc_del_fdb_peers_flow+0xcf/0x240 [mlx5_core]<br /> [ 3103.008463] mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]<br /> [ 3103.008944] mlx5e_flow_put+0x26/0x50 [mlx5_core]<br /> [ 3103.009401] mlx5e_delete_flower+0x25f/0x380 [mlx5_core]<br /> [ 3103.009901] tc_setup_cb_destroy+0xab/0x180<br /> [ 3103.010292] fl_hw_destroy_filter+0x99/0xc0 [cls_flower]<br /> [ 3103.010779] __fl_delete+0x2d4/0x2f0 [cls_flower]<br /> [ 3103.0<br /> ---truncated---