Vulnerabilities

A vulnerability has been found in SourceCodester Online Student File Management System 1.0. Affected by this issue is some unknown functionality of the file /admin/delete_user.php. The manipulation of the argument user_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 Online Exam Form Submission 1.0. This affects an unknown part of the file /index.php. The manipulation of the argument usn results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: fix mem leak in capture user mappings<br /> <br /> This commit fixes a memory leak caused when clearing the user_mappings<br /> info when a new context is opened immediately after user_mapping is<br /> captured and a hard reset is performed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race issue between cpu buffer write and swap<br /> <br /> Warning happened in rb_end_commit() at code:<br /> if (RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing)))<br /> <br /> WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142<br /> rb_commit+0x402/0x4a0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x42/0x250<br /> trace_buffer_unlock_commit_regs+0x3b/0x250<br /> trace_event_buffer_commit+0xe5/0x440<br /> trace_event_buffer_reserve+0x11c/0x150<br /> trace_event_raw_event_sched_switch+0x23c/0x2c0<br /> __traceiter_sched_switch+0x59/0x80<br /> __schedule+0x72b/0x1580<br /> schedule+0x92/0x120<br /> worker_thread+0xa0/0x6f0<br /> <br /> It is because the race between writing event into cpu buffer and swapping<br /> cpu buffer through file per_cpu/cpu0/snapshot:<br /> <br /> Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1<br /> -------- --------<br /> tracing_snapshot_write()<br /> [...]<br /> <br /> ring_buffer_lock_reserve()<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 1. Suppose find &amp;#39;cpu_buffer_a&amp;#39;;<br /> [...]<br /> rb_reserve_next_event()<br /> [...]<br /> <br /> ring_buffer_swap_cpu()<br /> if (local_read(&amp;cpu_buffer_a-&gt;committing))<br /> goto out_dec;<br /> if (local_read(&amp;cpu_buffer_b-&gt;committing))<br /> goto out_dec;<br /> buffer_a-&gt;buffers[cpu] = cpu_buffer_b;<br /> buffer_b-&gt;buffers[cpu] = cpu_buffer_a;<br /> // 2. cpu_buffer has swapped here.<br /> <br /> rb_start_commit(cpu_buffer);<br /> if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer)<br /> != buffer)) { // 3. This check passed due to &amp;#39;cpu_buffer-&gt;buffer&amp;#39;<br /> [...] // has not changed here.<br /> return NULL;<br /> }<br /> cpu_buffer_b-&gt;buffer = buffer_a;<br /> cpu_buffer_a-&gt;buffer = buffer_b;<br /> [...]<br /> <br /> // 4. Reserve event from &amp;#39;cpu_buffer_a&amp;#39;.<br /> <br /> ring_buffer_unlock_commit()<br /> [...]<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 5. Now find &amp;#39;cpu_buffer_b&amp;#39; !!!<br /> rb_commit(cpu_buffer)<br /> rb_end_commit() // 6. WARN for the wrong &amp;#39;committing&amp;#39; state !!!<br /> <br /> Based on above analysis, we can easily reproduce by following testcase:<br /> ``` bash<br /> #!/bin/bash<br /> <br /> dmesg -n 7<br /> sysctl -w kernel.panic_on_warn=1<br /> TR=/sys/kernel/tracing<br /> echo 7 &gt; ${TR}/buffer_size_kb<br /> echo "sched:sched_switch" &gt; ${TR}/set_event<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> ```<br /> <br /> To fix it, IIUC, we can use smp_call_function_single() to do the swap on<br /> the target cpu where the buffer is located, so that above race would be<br /> avoided.

Use of Hard-coded Credentials vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5 and newer versions

Use of a One-Way Hash with a Predictable Salt vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. and newer versions

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.2: Rework scratch handling for READ_PLUS (again)<br /> <br /> I found that the read code might send multiple requests using the same<br /> nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is<br /> how we ended up occasionally double-freeing the scratch buffer, but also<br /> means we set a NULL pointer but non-zero length to the xdr scratch<br /> buffer. This results in an oops the first time decoding needs to copy<br /> something to scratch, which frequently happens when decoding READ_PLUS<br /> hole segments.<br /> <br /> I fix this by moving scratch handling into the pageio read code. I<br /> provide a function to allocate scratch space for decoding read replies,<br /> and free the scratch buffer when the nfs_pgio_header is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: mm: Add p?d_leaf() definitions<br /> <br /> When I do LTP test, LTP test case ksm06 caused panic at<br /> break_ksm_pmd_entry<br /> -&gt; pmd_leaf (Huge page table but False)<br /> -&gt; pte_present (panic)<br /> <br /> The reason is pmd_leaf() is not defined, So like commit 501b81046701<br /> ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for<br /> LoongArch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: don&amp;#39;t assume child devices are all fsl-mc devices<br /> <br /> Changes in VFIO caused a pseudo-device to be created as child of<br /> fsl-mc devices causing a crash [1] when trying to bind a fsl-mc<br /> device to VFIO. Fix this by checking the device type when enumerating<br /> fsl-mc child devices.<br /> <br /> [1]<br /> Modules linked in:<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2<br /> Hardware name: NXP Layerscape LX2160ARDB (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mc_send_command+0x24/0x1f0<br /> lr : dprc_get_obj_region+0xfc/0x1c0<br /> sp : ffff80000a88b900<br /> x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2<br /> x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000<br /> x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001<br /> x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff<br /> x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386<br /> x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012<br /> x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8<br /> x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80<br /> Call trace:<br /> mc_send_command+0x24/0x1f0<br /> dprc_get_obj_region+0xfc/0x1c0<br /> fsl_mc_device_add+0x340/0x590<br /> fsl_mc_obj_device_add+0xd0/0xf8<br /> dprc_scan_objects+0x1c4/0x340<br /> dprc_scan_container+0x38/0x60<br /> vfio_fsl_mc_probe+0x9c/0xf8<br /> fsl_mc_driver_probe+0x24/0x70<br /> really_probe+0xbc/0x2a8<br /> __driver_probe_device+0x78/0xe0<br /> device_driver_attach+0x30/0x68<br /> bind_store+0xa8/0x130<br /> drv_attr_store+0x24/0x38<br /> sysfs_kf_write+0x44/0x60<br /> kernfs_fop_write_iter+0x128/0x1b8<br /> vfs_write+0x334/0x448<br /> ksys_write+0x68/0xf0<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x108<br /> el0_svc_common.constprop.1+0x94/0xf8<br /> do_el0_svc+0x38/0xb0<br /> el0_svc+0x20/0x50<br /> el0t_64_sync_handler+0x98/0xc0<br /> el0t_64_sync+0x174/0x178<br /> Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix use-after-free in pci_bus_release_domain_nr()<br /> <br /> Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")<br /> introduced a use-after-free bug in the bus removal cleanup. The issue was<br /> found with kfence:<br /> <br /> [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70<br /> <br /> [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115):<br /> [ 19.309677] pci_bus_release_domain_nr+0x10/0x70<br /> [ 19.309691] dw_pcie_host_deinit+0x28/0x78<br /> [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]<br /> [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]<br /> [ 19.309752] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k<br /> <br /> [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s:<br /> [ 19.311562] __kmem_cache_alloc_node+0x260/0x278<br /> [ 19.311571] kmalloc_trace+0x24/0x30<br /> [ 19.311580] pci_alloc_bus+0x24/0xa0<br /> [ 19.311590] pci_register_host_bridge+0x48/0x4b8<br /> [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8<br /> [ 19.311613] pci_host_probe+0x18/0xc0<br /> [ 19.311623] dw_pcie_host_init+0x2c0/0x568<br /> [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194]<br /> [ 19.311647] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.311782] freed by task 96 on cpu 10 at 19.285833s:<br /> [ 19.311799] release_pcibus_dev+0x30/0x40<br /> [ 19.311808] device_release+0x30/0x90<br /> [ 19.311814] kobject_put+0xa8/0x120<br /> [ 19.311832] device_unregister+0x20/0x30<br /> [ 19.311839] pci_remove_bus+0x78/0x88<br /> [ 19.311850] pci_remove_root_bus+0x5c/0x98<br /> [ 19.311860] dw_pcie_host_deinit+0x28/0x78<br /> [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]<br /> [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]<br /> [ 19.311900] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4<br /> [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022<br /> [ 19.325852] Workqueue: events_unbound deferred_probe_work_func<br /> <br /> The stack trace is a bit misleading as dw_pcie_host_deinit() doesn&amp;#39;t<br /> directly call pci_bus_release_domain_nr(). The issue turns out to be in<br /> pci_remove_root_bus() which first calls pci_remove_bus() which frees the<br /> struct pci_bus when its struct device is released. Then<br /> pci_bus_release_domain_nr() is called and accesses the freed struct<br /> pci_bus. Reordering these fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9063: better fix null deref with partial DT<br /> <br /> Two versions of the original patch were sent but V1 was merged instead<br /> of V2 due to a mistake.<br /> <br /> So update to V2.<br /> <br /> The advantage of V2 is that it completely avoids dereferencing the pointer,<br /> even just to take the address, which may fix problems with some compilers.<br /> Both versions work on my gcc 9.4 but use the safer one.