Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: explicitly clear the sk pointer, when pf-&gt;create fails<br /> <br /> We have recently noticed the exact same KASAN splat as in commit<br /> 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket<br /> creation fails"). The problem is that commit did not fully address the<br /> problem, as some pf-&gt;create implementations do not use sk_common_release<br /> in their error paths.<br /> <br /> For example, we can use the same reproducer as in the above commit, but<br /> changing ping to arping. arping uses AF_PACKET socket and if packet_create<br /> fails, it will just sk_free the allocated sk object.<br /> <br /> While we could chase all the pf-&gt;create implementations and make sure they<br /> NULL the freed sk object on error from the socket, we can&amp;#39;t guarantee<br /> future protocols will not make the same mistake.<br /> <br /> So it is easier to just explicitly NULL the sk pointer upon return from<br /> pf-&gt;create in __sock_create. We do know that pf-&gt;create always releases the<br /> allocated sk object on error, so if the pointer is not NULL, it is<br /> definitely dangling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Stop the active perfmon before being destroyed<br /> <br /> Upon closing the file descriptor, the active performance monitor is not<br /> stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,<br /> the active performance monitor&amp;#39;s pointer (`vc4-&gt;active_perfmon`) is still<br /> retained.<br /> <br /> If we open a new file descriptor and submit a few jobs with performance<br /> monitors, the driver will attempt to stop the active performance monitor<br /> using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer<br /> is no longer valid because the previous process has already terminated,<br /> and all performance monitors associated with it have been destroyed and<br /> freed.<br /> <br /> To fix this, when the active performance monitor belongs to a given<br /> process, explicitly stop it before destroying and freeing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()<br /> <br /> Using the device-managed version allows to simplify clean-up in probe()<br /> error path.<br /> <br /> Additionally, this device-managed ensures proper cleanup, which helps to<br /> resolve memory errors, page faults, btrfs going read-only, and btrfs<br /> disk corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: dp83869: fix memory corruption when enabling fiber<br /> <br /> When configuring the fiber port, the DP83869 PHY driver incorrectly<br /> calls linkmode_set_bit() with a bit mask (1

A vulnerability, which was classified as critical, was found in Codezips Online Institute Management System 1.0. Affected is an unknown function of the file /manage_website.php. The manipulation of the argument website_image leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability has been found in Codezips Online Institute Management System 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /edit_user.php. The manipulation of the argument image leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()<br /> <br /> The group variable can&amp;#39;t be used to retrieve ptdev in our second loop,<br /> because it points to the previously iterated list_head, not a valid<br /> group. Get the ptdev object from the scheduler instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix race when converting group handle to group object<br /> <br /> XArray provides it&amp;#39;s own internal lock which protects the internal array<br /> when entries are being simultaneously added and removed. However there<br /> is still a race between retrieving the pointer from the XArray and<br /> incrementing the reference count.<br /> <br /> To avoid this race simply hold the internal XArray lock when<br /> incrementing the reference count, this ensures there cannot be a racing<br /> call to xa_erase().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: qcom: camss: Remove use_count guard in stop_streaming<br /> <br /> The use_count check was introduced so that multiple concurrent Raw Data<br /> Interfaces RDIs could be driven by different virtual channels VCs on the<br /> CSIPHY input driving the video pipeline.<br /> <br /> This is an invalid use of use_count though as use_count pertains to the<br /> number of times a video entity has been opened by user-space not the number<br /> of active streams.<br /> <br /> If use_count and stream-on count don&amp;#39;t agree then stop_streaming() will<br /> break as is currently the case and has become apparent when using CAMSS<br /> with libcamera&amp;#39;s released softisp 0.3.<br /> <br /> The use of use_count like this is a bit hacky and right now breaks regular<br /> usage of CAMSS for a single stream case. Stopping qcam results in the splat<br /> below, and then it cannot be started again and any attempts to do so fails<br /> with -EBUSY.<br /> <br /> [ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]<br /> ...<br /> [ 1265.510630] Call trace:<br /> [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]<br /> [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common]<br /> [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2]<br /> [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev]<br /> [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev]<br /> [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev]<br /> [ 1265.510757] video_ioctl2+0x18/0x34 [videodev]<br /> [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev]<br /> ...<br /> [ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state<br /> [ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state<br /> [ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st<br /> <br /> One CAMSS specific way to handle multiple VCs on the same RDI might be:<br /> <br /> - Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx.<br /> - The video buffers are already associated with msm_vfeN_rdiX so<br /> release video buffers when told to do so by stop_streaming.<br /> - Only release the power-domains for the CSIPHY, CSID and VFE when<br /> their internal refcounts drop.<br /> <br /> Either way refusing to release video buffers based on use_count is<br /> erroneous and should be reverted. The silicon enabling code for selecting<br /> VCs is perfectly fine. Its a "known missing feature" that concurrent VCs<br /> won&amp;#39;t work with CAMSS right now.<br /> <br /> Initial testing with this code didn&amp;#39;t show an error but, SoftISP and "real"<br /> usage with Google Hangouts breaks the upstream code pretty quickly, we need<br /> to do a partial revert and take another pass at VCs.<br /> <br /> This commit partially reverts commit 89013969e232 ("media: camss: sm8250:<br /> Pipeline starting and stopping for multiple virtual channels")

The Simple Shortcode for Google Maps plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s pw_map shortcode in all versions up to, and including, 1.5.4 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

A vulnerability, which was classified as critical, has been found in Codezips Hospital Appointment System 1.0. This issue affects some unknown processing of the file /editBranchResult.php. The manipulation of the argument ID leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

Versions of the package cross-spawn before 6.0.6, from 7.0.0 and before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.