Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: remove the incorrect Fw reference check when dirtying pages<br /> <br /> When doing the direct-io reads it will also try to mark pages dirty,<br /> but for the read path it won&amp;#39;t hold the Fw caps and there is case<br /> will it get the Fw reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: sisfb: Fix strbuf array overflow<br /> <br /> The values of the variables xres and yres are placed in strbuf.<br /> These variables are obtained from strbuf1.<br /> The strbuf1 array contains digit characters<br /> and a space if the array contains non-digit characters.<br /> Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres);<br /> more than 16 bytes will be written to strbuf.<br /> It is suggested to increase the size of the strbuf array to 24.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> secretmem: disable memfd_secret() if arch cannot set direct map<br /> <br /> Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This<br /> is the case for example on some arm64 configurations, where marking 4k<br /> PTEs in the direct map not present can only be done if the direct map is<br /> set up at 4k granularity in the first place (as ARM&amp;#39;s break-before-make<br /> semantics do not easily allow breaking apart large/gigantic pages).<br /> <br /> More precisely, on arm64 systems with !can_set_direct_map(),<br /> set_direct_map_invalid_noflush() is a no-op, however it returns success<br /> (0) instead of an error. This means that memfd_secret will seemingly<br /> "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),<br /> but it does not actually achieve its goal of removing its memory from the<br /> direct map.<br /> <br /> Note that with this patch, memfd_secret() will start erroring on systems<br /> where can_set_direct_map() returns false (arm64 with<br /> CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and<br /> CONFIG_KFENCE=n), but that still seems better than the current silent<br /> failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to &amp;#39;y&amp;#39;, most<br /> arm64 systems actually have a working memfd_secret() and aren&amp;#39;t be<br /> affected.<br /> <br /> From going through the iterations of the original memfd_secret patch<br /> series, it seems that disabling the syscall in these scenarios was the<br /> intended behavior [1] (preferred over having<br /> set_direct_map_invalid_noflush return an error as that would result in<br /> SIGBUSes at page-fault time), however the check for it got dropped between<br /> v16 [2] and v17 [3], when secretmem moved away from CMA allocations.<br /> <br /> [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/<br /> [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t<br /> [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/

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 /> 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

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.

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.