Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag<br /> <br /> Truncate an inode&amp;#39;s address space when flipping the GFS2_DIF_JDATA flag:<br /> depending on that flag, the pages in the address space will either use<br /> buffer heads or iomap_folio_state structs, and we cannot mix the two.

A vulnerability was found in SourceCodester Best Church Management Software 1.1. It has been declared as critical. This vulnerability affects unknown code of the file /admin/app/slider_crud.php. The manipulation of the argument del_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in SourceCodester Best Church Management Software 1.1. It has been rated as critical. This issue affects some unknown processing of the file /admin/app/profile_crud.php. The manipulation leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Multiple parameters might be affected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-uart-backlight: fix serdev race<br /> <br /> The dell_uart_bl_serdev_probe() function calls devm_serdev_device_open()<br /> before setting the client ops via serdev_device_set_client_ops(). This<br /> ordering can trigger a NULL pointer dereference in the serdev controller&amp;#39;s<br /> receive_buf handler, as it assumes serdev-&gt;ops is valid when<br /> SERPORT_ACTIVE is set.<br /> <br /> This is similar to the issue fixed in commit 5e700b384ec1<br /> ("platform/chrome: cros_ec_uart: properly fix race condition") where<br /> devm_serdev_device_open() was called before fully initializing the<br /> device.<br /> <br /> Fix the race by ensuring client ops are set before enabling the port via<br /> devm_serdev_device_open().<br /> <br /> Note, serdev_device_set_baudrate() and serdev_device_set_flow_control()<br /> calls should be after the devm_serdev_device_open() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: clear uffd-wp PTE/PMD state on mremap()<br /> <br /> When mremap()ing a memory region previously registered with userfaultfd as<br /> write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in<br /> flag clearing leads to a mismatch between the vma flags (which have<br /> uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp<br /> cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) to<br /> trigger a warning in page_table_check_pte_flags() due to setting the pte<br /> to writable while uffd-wp is still set.<br /> <br /> Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any<br /> such mremap() so that the values are consistent with the existing clearing<br /> of VM_UFFD_WP. Be careful to clear the logical flag regardless of its<br /> physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE,<br /> huge PMD and hugetlb paths.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc: fix softlockup in __read_vmcore (part 2)<br /> <br /> Since commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore") the<br /> number of softlockups in __read_vmcore at kdump time have gone down, but<br /> they still happen sometimes.<br /> <br /> In a memory constrained environment like the kdump image, a softlockup is<br /> not just a harmless message, but it can interfere with things like RCU<br /> freeing memory, causing the crashdump to get stuck.<br /> <br /> The second loop in __read_vmcore has a lot more opportunities for natural<br /> sleep points, like scheduling out while waiting for a data write to<br /> happen, but apparently that is not always enough.<br /> <br /> Add a cond_resched() to the second loop in __read_vmcore to (hopefully)<br /> get rid of the softlockups.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Ensure job pointer is set to NULL after job completion<br /> <br /> After a job completes, the corresponding pointer in the device must<br /> be set to NULL. Failing to do so triggers a warning when unloading<br /> the driver, as it appears the job is still active. To prevent this,<br /> assign the job pointer to NULL after completing the job, indicating<br /> the job has finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "libfs: fix infinite directory reads for offset dir"<br /> <br /> The current directory offset allocator (based on mtree_alloc_cyclic)<br /> stores the next offset value to return in octx-&gt;next_offset. This<br /> mechanism typically returns values that increase monotonically over<br /> time. Eventually, though, the newly allocated offset value wraps<br /> back to a low number (say, 2) which is smaller than other already-<br /> allocated offset values.<br /> <br /> Yu Kuai reports that, after commit 64a7ce76fb90<br /> ("libfs: fix infinite directory reads for offset dir"), if a<br /> directory&amp;#39;s offset allocator wraps, existing entries are no longer<br /> visible via readdir/getdents because offset_readdir() stops listing<br /> entries once an entry&amp;#39;s offset is larger than octx-&gt;next_offset.<br /> These entries vanish persistently -- they can be looked up, but will<br /> never again appear in readdir(3) output.<br /> <br /> The reason for this is that the commit treats directory offsets as<br /> monotonically increasing integer values rather than opaque cookies,<br /> and introduces this comparison:<br /> <br /> if (dentry2offset(dentry) &gt;= last_index) {<br /> <br /> On 64-bit platforms, the directory offset value upper bound is<br /> 2^63 - 1. Directory offsets will monotonically increase for millions<br /> of years without wrapping.<br /> <br /> On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator<br /> can wrap after only a few weeks (at worst).<br /> <br /> Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for<br /> offset dir") to prepare for a fix that can work properly on 32-bit<br /> systems and might apply to recent LTS kernels where shmem employs<br /> the simple_offset mechanism.

A CWE-259 "Use of Hard-coded Password" for the root account in Q-Free MaxTime less than or equal to version 2.11.0 allows an unauthenticated remote attacker to execute arbitrary code with root privileges via SSH.

A CWE-204 "Observable Response Discrepancy" in the login page in Q-Free MaxTime less than or equal to version 2.11.0 allows an unauthenticated remote attacker to enumerate valid usernames via crafted HTTP requests.

A CWE-346 "Origin Validation Error" in the CORS configuration in Q-Free MaxTime less than or equal to version 2.11.0 allows an unauthenticated remote attacker to affect the device confidentiality, integrity, or availability via crafted URLs or HTTP requests.