Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance<br /> <br /> Deleting an NPIV instance requires all fabric ndlps to be released before<br /> an NPIV&amp;#39;s resources can be torn down. Failure to release fabric ndlps<br /> beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID<br /> to complete synchronously with usage of wait_queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pmem: Check device status before requesting flush<br /> <br /> If a pmem device is in a bad status, the driver side could wait for<br /> host ack forever in virtio_pmem_flush(), causing the system to hang.<br /> <br /> So add a status check in the beginning of virtio_pmem_flush() to return<br /> early if the device is not activated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: handle consistently DSS corruption<br /> <br /> Bugged peer implementation can send corrupted DSS options, consistently<br /> hitting a few warning in the data path. Use DEBUG_NET assertions, to<br /> avoid the splat on some builds and handle consistently the error, dumping<br /> related MIBs and performing fallback and/or reset according to the<br /> subflow type.

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")