Vulnerabilities

An Open Redirect vulnerability was found in Sipwise C5 NGCP Dashboard below mr11.5.1. The Open Redirect vulnerability allows attackers to control the "back" parameter in the URL through a double encoded URL.

An issue discovered in Sipwise C5 NGCP Dashboard below mr11.5.1 allows a low privileged user to access the Journal endpoint by directly visit the URL.

Cross-Site Request Forgery (CSRF) vulnerability in Hidekazu Ishikawa X-T9, Hidekazu Ishikawa Lightning, themeinwp Default Mag, Out the Box Namaha, Out the Box CityLogic, Marsian i-max, Jetmonsters Emmet Lite, Macho Themes Decode, Wayneconnor Sliding Door, Out the Box Shopstar!, Modernthemesnet Gridsby, TT Themes HappenStance, Marsian i-excel, Out the Box Panoramic, Modernthemesnet Sensible WP.This issue affects X-T9: from n/a through 1.19.0; Lightning: from n/a through 15.18.0; Default Mag: from n/a through 1.3.5; Namaha: from n/a through 1.0.40; CityLogic: from n/a through 1.1.29; i-max: from n/a through 1.6.2; Emmet Lite: from n/a through 1.7.5; Decode: from n/a through 3.15.3; Sliding Door: from n/a through 3.3; Shopstar!: from n/a through 1.1.33; Gridsby: from n/a through 1.3.0; HappenStance: from n/a through 3.0.1; i-excel: from n/a through 1.7.9; Panoramic: from n/a through 1.1.56; Sensible WP: from n/a through 1.3.1.<br /> <br />

XWiki Platform is a generic wiki platform. Starting in version 5.0-rc-1 and prior to versions 14.10.19, 15.5.4, and 15.9-rc-1, it is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it&amp;#39;s possible for an attacker to have access to the hash password of a user if they have rights to edit the users&amp;#39; page. With the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there. a diff, to ensure it&amp;#39;s not coming from a password field. As another mitigation, admins should ensure that the user pages are properly protected: the edit right shouldn&amp;#39;t be allowed for other users than Admin and owner of the profile (which is the default right). There is not much workaround possible for a privileged user other than upgrading XWiki.

Out of bounds memory access in Compositing in Google Chrome prior to 123.0.6312.122 allowed a remote attacker who had compromised the GPU process to potentially perform a sandbox escape via specific UI gestures. (Chromium security severity: High)

Use after free in Dawn in Google Chrome prior to 123.0.6312.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Heap buffer overflow in ANGLE in Google Chrome prior to 123.0.6312.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: CT, Fix multiple allocations and memleak of mod acts<br /> <br /> CT clear action offload adds additional mod hdr actions to the<br /> flow&amp;#39;s original mod actions in order to clear the registers which<br /> hold ct_state.<br /> When such flow also includes encap action, a neigh update event<br /> can cause the driver to unoffload the flow and then reoffload it.<br /> <br /> Each time this happens, the ct clear handling adds that same set<br /> of mod hdr actions to reset ct_state until the max of mod hdr<br /> actions is reached.<br /> <br /> Also the driver never releases the allocated mod hdr actions and<br /> causing a memleak.<br /> <br /> Fix above two issues by moving CT clear mod acts allocation<br /> into the parsing actions phase and only use it when offloading the rule.<br /> The release of mod acts will be done in the normal flow_put().<br /> <br /> backtrace:<br /> [] krealloc+0x83/0xd0<br /> [] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]<br /> [] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]<br /> [] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]<br /> [] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]<br /> [] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]<br /> [] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]<br /> [] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]<br /> [] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]<br /> [] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap<br /> <br /> drm_gem_ttm_mmap() drops a reference to the gem object on success. If<br /> the gem object&amp;#39;s refcount == 1 on entry to drm_gem_prime_mmap(), that<br /> drop will free the gem object, and the subsequent drm_gem_object_get()<br /> will be a UAF. Fix by grabbing a reference before calling the mmap<br /> helper.<br /> <br /> This issue was forseen when the reference dropping was adding in<br /> commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):<br /> "For that to work properly the drm_gem_object_get() call in<br /> drm_gem_ttm_mmap() must be moved so it happens before calling<br /> obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down<br /> to zero."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: free q_vectors before queues in iavf_disable_vf<br /> <br /> iavf_free_queues() clears adapter-&gt;num_active_queues, which<br /> iavf_free_q_vectors() relies on, so swap the order of these two function<br /> calls in iavf_disable_vf(). This resolves a panic encountered when the<br /> interface is disabled and then later brought up again after PF<br /> communication is restored.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: Fix NULL pointer dereferences in of_thermal_ functions<br /> <br /> of_parse_thermal_zones() parses the thermal-zones node and registers a<br /> thermal_zone device for each subnode. However, if a thermal zone is<br /> consuming a thermal sensor and that thermal sensor device hasn&amp;#39;t probed<br /> yet, an attempt to set trip_point_*_temp for that thermal zone device<br /> can cause a NULL pointer dereference. Fix it.<br /> <br /> console:/sys/class/thermal/thermal_zone87 # echo 120000 &gt; trip_point_0_temp<br /> ...<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ...<br /> Call trace:<br /> of_thermal_set_trip_temp+0x40/0xc4<br /> trip_point_temp_store+0xc0/0x1dc<br /> dev_attr_store+0x38/0x88<br /> sysfs_kf_write+0x64/0xc0<br /> kernfs_fop_write_iter+0x108/0x1d0<br /> vfs_write+0x2f4/0x368<br /> ksys_write+0x7c/0xec<br /> __arm64_sys_write+0x20/0x30<br /> el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc<br /> do_el0_svc+0x28/0xa0<br /> el0_svc+0x14/0x24<br /> el0_sync_handler+0x88/0xec<br /> el0_sync+0x1c0/0x200<br /> <br /> While at it, fix the possible NULL pointer dereference in other<br /> functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),<br /> of_thermal_get_trend().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()<br /> <br /> When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass<br /> the requests to the adapter. If such an attempt fails, a local "fail_msg"<br /> string is set and a log message output. The job is then added to a<br /> completions list for cancellation.<br /> <br /> Processing of any further jobs from the txq list continues, but since<br /> "fail_msg" remains set, jobs are added to the completions list regardless<br /> of whether a wqe was passed to the adapter. If successfully added to<br /> txcmplq, jobs are added to both lists resulting in list corruption.<br /> <br /> Fix by clearing the fail_msg string after adding a job to the completions<br /> list. This stops the subsequent jobs from being added to the completions<br /> list unless they had an appropriate failure.