Vulnerabilities

A vulnerability was found in SourceCodester Online Student Clearance System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/edit-admin.php. The manipulation of the argument txtfullname/txtemail/cmddesignation leads to sql injection. The attack can be initiated 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 /> ASoC: ops: Consistently treat platform_max as control value<br /> <br /> This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in<br /> snd_soc_put_volsw() by +min"), and makes some additional related<br /> updates.<br /> <br /> There are two ways the platform_max could be interpreted; the maximum<br /> register value, or the maximum value the control can be set to. The<br /> patch moved from treating the value as a control value to a register<br /> one. When the patch was applied it was technically correct as<br /> snd_soc_limit_volume() also used the register interpretation. However,<br /> even then most of the other usages treated platform_max as a<br /> control value, and snd_soc_limit_volume() has since been updated to<br /> also do so in commit fb9ad24485087 ("ASoC: ops: add correct range<br /> check for limiting volume"). That patch however, missed updating<br /> snd_soc_put_volsw() back to the control interpretation, and fixing<br /> snd_soc_info_volsw_range(). The control interpretation makes more<br /> sense as limiting is typically done from the machine driver, so it is<br /> appropriate to use the customer facing representation rather than the<br /> internal codec representation. Update all the code to consistently use<br /> this interpretation of platform_max.<br /> <br /> Finally, also add some comments to the soc_mixer_control struct to<br /> hopefully avoid further patches switching between the two approaches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init<br /> <br /> Move the get_ctx(child_ctx) call and the child_event-&gt;ctx assignment to<br /> occur immediately after the child event is allocated. Ensure that<br /> child_event-&gt;ctx is non-NULL before any subsequent error path within<br /> inherit_event calls free_event(), satisfying the assumptions of the<br /> cleanup code.<br /> <br /> Details:<br /> <br /> There&amp;#39;s no clear Fixes tag, because this bug is a side-effect of<br /> multiple interacting commits over time (up to 15 years old), not<br /> a single regression.<br /> <br /> The code initially incremented refcount then assigned context<br /> immediately after the child_event was created. Later, an early<br /> validity check for child_event was added before the<br /> refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was<br /> added, assuming event-&gt;ctx is valid if the pmu_ctx is valid.<br /> The problem is that the WARN_ON_ONCE() could trigger after the initial<br /> check passed but before child_event-&gt;ctx was assigned, violating its<br /> precondition. The solution is to assign child_event-&gt;ctx right after<br /> its initial validation. This ensures the context exists for any<br /> subsequent checks or cleanup routines, resolving the WARN_ON_ONCE().<br /> <br /> To resolve it, defer the refcount update and child_event-&gt;ctx assignment<br /> directly after child_event-&gt;pmu_ctx is set but before checking if the<br /> parent event is orphaned. The cleanup routine depends on<br /> event-&gt;pmu_ctx being non-NULL before it verifies event-&gt;ctx is<br /> non-NULL. This also maintains the author&amp;#39;s original intent of passing<br /> in child_ctx to find_get_pmu_context before its refcount/assignment.<br /> <br /> [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/net: fix improper handling of bogus negative read/write replies<br /> <br /> In p9_client_write() and p9_client_read_once(), if the server<br /> incorrectly replies with success but a negative write/read count then we<br /> would consider written (negative) 3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: work around sched_yield not yielding in time-travel mode<br /> <br /> sched_yield by a userspace may not actually cause scheduling in<br /> time-travel mode as no time has passed. In the case seen it appears to<br /> be a badly implemented userspace spinlock in ASAN. Unfortunately, with<br /> time-travel it causes an extreme slowdown or even deadlock depending on<br /> the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS).<br /> <br /> Work around it by accounting time to the process whenever it executes a<br /> sched_yield syscall.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()<br /> <br /> The variable d-&gt;name, returned by devm_kasprintf(), could be NULL.<br /> A pointer check is added to prevent potential NULL pointer dereference.<br /> This is similar to the fix in commit 3027e7b15b02<br /> ("ice: Fix some null pointer dereference issues in ice_ptp.c").<br /> <br /> This issue is found by our static analysis tool

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix isochronous Ring Underrun/Overrun event handling<br /> <br /> The TRB pointer of these events points at enqueue at the time of error<br /> occurrence on xHCI 1.1+ HCs or it&amp;#39;s NULL on older ones. By the time we<br /> are handling the event, a new TD may be queued at this ring position.<br /> <br /> I can trigger this race by rising interrupt moderation to increase IRQ<br /> handling delay. Similar delay may occur naturally due to system load.<br /> <br /> If this ever happens after a Missed Service Error, missed TDs will be<br /> skipped and the new TD processed as if it matched the event. It could<br /> be given back prematurely, risking data loss or buffer UAF by the xHC.<br /> <br /> Don&amp;#39;t complete TDs on xrun events and don&amp;#39;t warn if queued TDs don&amp;#39;t<br /> match the event&amp;#39;s TRB pointer, which can be NULL or a link/no-op TRB.<br /> Don&amp;#39;t warn if there are no queued TDs at all.<br /> <br /> Now that it&amp;#39;s safe, also handle xrun events if the skip flag is clear.<br /> This ensures completion of any TD stuck in &amp;#39;error mid TD&amp;#39; state right<br /> before the xrun event, which could happen if a driver submits a finite<br /> number of URBs to a buggy HC and then an error occurs on the last TD.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Add check for get_zeroed_page()<br /> <br /> Add check for the return value of get_zeroed_page() in<br /> sclp_console_init() to prevent null pointer dereference.<br /> Furthermore, to solve the memory leak caused by the loop<br /> allocation, add a free helper to do the free job.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix deadlock between rcu_tasks_trace and event_mutex.<br /> <br /> Fix the following deadlock:<br /> CPU A<br /> _free_event()<br /> perf_kprobe_destroy()<br /> mutex_lock(&amp;event_mutex)<br /> perf_trace_event_unreg()<br /> synchronize_rcu_tasks_trace()<br /> <br /> There are several paths where _free_event() grabs event_mutex<br /> and calls sync_rcu_tasks_trace. Above is one such case.<br /> <br /> CPU B<br /> bpf_prog_test_run_syscall()<br /> rcu_read_lock_trace()<br /> bpf_prog_run_pin_on_cpu()<br /> bpf_prog_load()<br /> bpf_tracing_func_proto()<br /> trace_set_clr_event()<br /> mutex_lock(&amp;event_mutex)<br /> <br /> Delegate trace_set_clr_event() to workqueue to avoid<br /> such lock dependency.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Reset IRTE to host control if *new* route isn&amp;#39;t postable<br /> <br /> Restore an IRTE back to host control (remapped or posted MSI mode) if the<br /> *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of<br /> the GSI routing type. Updating the IRTE if and only if the new GSI is an<br /> MSI results in KVM leaving an IRTE posting to a vCPU.<br /> <br /> The dangling IRTE can result in interrupts being incorrectly delivered to<br /> the guest, and in the worst case scenario can result in use-after-free,<br /> e.g. if the VM is torn down, but the underlying host IRQ isn&amp;#39;t freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: make wait_context part of q_info<br /> <br /> Make the wait_context a full part of the q_info struct rather<br /> than a stack variable that goes away after pdsc_adminq_post()<br /> is done so that the context is still available after the wait<br /> loop has given up.<br /> <br /> There was a case where a slow development firmware caused<br /> the adminq request to time out, but then later the FW finally<br /> finished the request and sent the interrupt. The handler tried<br /> to complete_all() the completion context that had been created<br /> on the stack in pdsc_adminq_post() but no longer existed.<br /> This caused bad pointer usage, kernel crashes, and much wailing<br /> and gnashing of teeth.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: prevent hang on link training fail<br /> <br /> [Why]<br /> When link training fails, the phy clock will be disabled. However, in<br /> enable_streams, it is assumed that link training succeeded and the<br /> mux selects the phy clock, causing a hang when a register write is made.<br /> <br /> [How]<br /> When enable_stream is hit, check if link training failed. If it did, fall<br /> back to the ref clock to avoid a hang and keep the system in a recoverable<br /> state.