Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hrtimers: Handle CPU state correctly on hotplug<br /> <br /> Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway<br /> through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to<br /> CPUHP_ONLINE:<br /> <br /> Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set<br /> to 1 throughout. However, during a CPU unplug operation, the tick and the<br /> clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online<br /> state, for instance CFS incorrectly assumes that the hrtick is already<br /> active, and the chance of the clockevent device to transition to oneshot<br /> mode is also lost forever for the CPU, unless it goes back to a lower state<br /> than CPUHP_HRTIMERS_PREPARE once.<br /> <br /> This round-trip reveals another issue; cpu_base.online is not set to 1<br /> after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().<br /> <br /> Aside of that, the bulk of the per CPU state is not reset either, which<br /> means there are dangling pointers in the worst case.<br /> <br /> Address this by adding a corresponding startup() callback, which resets the<br /> stale per CPU state and sets the online flag.<br /> <br /> [ tglx: Make the new callback unconditionally available, remove the online<br /> modification in the prepare() callback and clear the remaining<br /> state in the starting callback instead of the prepare callback ]

HCL Connections Docs is vulnerable to a sensitive information disclosure which could allow a user to obtain sensitive information they are not entitled to, caused by improper handling of request data.