Vulnerabilities

SourceCodester Customer Support System 1.0 contains an incorrect access control vulnerability in ajax.php. The AJAX dispatcher does not enforce authentication or authorization before invoking administrative methods in admin_class.php based on the action parameter. An unauthenticated remote attacker can perform sensitive operations such as creating customers and deleting users (including the admin account), as well as modifying or deleting other application records (tickets, departments, comments), resulting in unauthorized data modification.

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2025-12500. Reason: This candidate is a reservation duplicate of CVE-2025-12500. Notes: All CVE users should reference CVE-2025-12500 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2025-12500. Reason: This candidate is a reservation duplicate of CVE-2025-12500. Notes: All CVE users should reference CVE-2025-12500 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: virtio - Add spinlock protection with virtqueue notification<br /> <br /> When VM boots with one virtio-crypto PCI device and builtin backend,<br /> run openssl benchmark command with multiple processes, such as<br /> openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32<br /> <br /> openssl processes will hangup and there is error reported like this:<br /> virtio_crypto virtio0: dataq.0:id 3 is not a head!<br /> <br /> It seems that the data virtqueue need protection when it is handled<br /> for virtio done notification. If the spinlock protection is added<br /> in virtcrypto_done_task(), openssl benchmark with multiple processes<br /> works well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()<br /> <br /> On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is<br /> freed via free_transport(), which does not decrement active_num_conn,<br /> leaking this counter.<br /> <br /> Replace free_transport() with ksmbd_tcp_disconnect().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix UAF in xchk_btree_check_block_owner<br /> <br /> We cannot dereference bs-&gt;cur when trying to determine if bs-&gt;cur<br /> aliases bs-&gt;sc-&gt;sa.{bno,rmap}_cur after the latter has been freed.<br /> Fix this by sampling before type before any freeing could happen.<br /> The correct temporal ordering was broken when we removed xfs_btnum_t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix UAF issue for file-backed mounts w/ directio option<br /> <br /> [ 9.269940][ T3222] Call trace:<br /> [ 9.269948][ T3222] ext4_file_read_iter+0xac/0x108<br /> [ 9.269979][ T3222] vfs_iocb_iter_read+0xac/0x198<br /> [ 9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180<br /> [ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24<br /> [ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac<br /> [ 9.270054][ T3222] z_erofs_read_folio+0x120/0x220<br /> [ 9.270083][ T3222] filemap_read_folio+0x60/0x120<br /> [ 9.270102][ T3222] filemap_fault+0xcac/0x1060<br /> [ 9.270119][ T3222] do_pte_missing+0x2d8/0x1554<br /> [ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c<br /> [ 9.270142][ T3222] do_page_fault+0x178/0x88c<br /> [ 9.270167][ T3222] do_translation_fault+0x38/0x54<br /> [ 9.270183][ T3222] do_mem_abort+0x54/0xac<br /> [ 9.270208][ T3222] el0_da+0x44/0x7c<br /> [ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4<br /> [ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0<br /> <br /> EROFS may encounter above panic when enabling file-backed mount w/<br /> directio mount option, the root cause is it may suffer UAF in below<br /> race condition:<br /> <br /> - z_erofs_read_folio wq s_dio_done_wq<br /> - z_erofs_runqueue<br /> - erofs_fileio_submit_bio<br /> - erofs_fileio_rq_submit<br /> - vfs_iocb_iter_read<br /> - ext4_file_read_iter<br /> - ext4_dio_read_iter<br /> - iomap_dio_rw<br /> : bio was submitted and return -EIOCBQUEUED<br /> - dio_aio_complete_work<br /> - dio_complete<br /> - dio-&gt;iocb-&gt;ki_complete (erofs_fileio_ki_complete())<br /> - kfree(rq)<br /> : it frees iocb, iocb.ki_filp can be UAF in file_accessed().<br /> - file_accessed<br /> : access NULL file point<br /> <br /> Introduce a reference count in struct erofs_fileio_rq, and initialize it<br /> as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will<br /> decrease reference count, the last one decreasing the reference count<br /> to zero will free rq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Don&amp;#39;t assume CID is CPU owned on mode switch<br /> <br /> Shinichiro reported a KASAN UAF, which is actually an out of bounds access<br /> in the MMCID management code.<br /> <br /> CPU0 CPU1<br /> T1 runs in userspace<br /> T0: fork(T4) -&gt; Switch to per CPU CID mode<br /> fixup() set MM_CID_TRANSIT on T1/CPU1<br /> T4 exit()<br /> T3 exit()<br /> T2 exit()<br /> T1 exit() switch to per task mode<br /> ---&gt; Out of bounds access.<br /> <br /> As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the<br /> TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in<br /> the task and drops the CID, but it does not touch the per CPU storage.<br /> That&amp;#39;s functionally correct because a CID is only owned by the CPU when<br /> the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.<br /> <br /> Now sched_mm_cid_exit() assumes that the CID is CPU owned because the<br /> prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the<br /> not set ONCPU bit and then invokes clear_bit() with an insanely large<br /> bit number because TRANSIT is set (bit 29).<br /> <br /> Prevent that by actually validating that the CID is CPU owned in<br /> mm_drop_cid_on_cpu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add chann_lock to protect ksmbd_chann_list xarray<br /> <br /> ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in<br /> multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del).<br /> <br /> Adds rw_semaphore chann_lock to struct ksmbd_session and protects<br /> all xa_load/xa_store/xa_erase accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos: vidi: use ctx-&gt;lock to protect struct vidi_context member variables related to memory alloc/free<br /> <br /> Exynos Virtual Display driver performs memory alloc/free operations<br /> without lock protection, which easily causes concurrency problem.<br /> <br /> For example, use-after-free can occur in race scenario like this:<br /> ```<br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> vidi_connection_ioctl()<br /> if (vidi-&gt;connection) // true<br /> drm_edid = drm_edid_alloc(); // alloc drm_edid<br /> ...<br /> ctx-&gt;raw_edid = drm_edid;<br /> ...<br /> drm_mode_getconnector()<br /> drm_helper_probe_single_connector_modes()<br /> vidi_get_modes()<br /> if (ctx-&gt;raw_edid) // true<br /> drm_edid_dup(ctx-&gt;raw_edid);<br /> if (!drm_edid) // false<br /> ...<br /> vidi_connection_ioctl()<br /> if (vidi-&gt;connection) // false<br /> drm_edid_free(ctx-&gt;raw_edid); // free drm_edid<br /> ...<br /> drm_edid_alloc(drm_edid-&gt;edid)<br /> kmemdup(edid); // UAF!!<br /> ...<br /> ```<br /> <br /> To prevent these vulns, at least in vidi_context, member variables related<br /> to memory alloc/free should be protected with ctx-&gt;lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: split cached_fid bitfields to avoid shared-byte RMW races<br /> <br /> is_open, has_lease and on_list are stored in the same bitfield byte in<br /> struct cached_fid but are updated in different code paths that may run<br /> concurrently. Bitfield assignments generate byte read–modify–write<br /> operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can<br /> restore stale values of the others.<br /> <br /> A possible interleaving is:<br /> CPU1: load old byte (has_lease=1, on_list=1)<br /> CPU2: clear both flags (store 0)<br /> CPU1: RMW store (old | IS_OPEN) -&gt; reintroduces cleared bits<br /> <br /> To avoid this class of races, convert these flags to separate bool<br /> fields.