| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability was found in a466350665 Smart-SSO up to 2.1.1. Affected by this issue is some unknown functionality of the file smart-sso-server/src/main/resources/templates/login.html of the component Login. Performing a manipulation of the argument redirectUri results in cross site scripting. The attack is possible to be carried out remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability has been found in datapizza-labs datapizza-ai 0.0.2. Affected by this vulnerability is the function RedisCache of the file datapizza-ai-cache/redis/datapizza/cache/redis/cache.py. Such manipulation leads to deserialization. The attack requires being on the local network. A high complexity level is associated with this attack. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A flaw has been found in datapizza-labs datapizza-ai 0.0.2. Affected is the function ChatPromptTemplate of the file datapizza-ai-core/datapizza/modules/prompt/prompt.py of the component Jinja2 Template Handler. This manipulation of the argument Prompt causes improper neutralization of special elements used in a template engine. Remote exploitation of the attack is possible. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| The vulnerability was rooted in how the Tassos Framework plugin handled specific AJAX requests through Joomla’s com_ajax entry point. Under certain conditions, internal framework functionality could be invoked without proper restriction. |
| A vulnerability was determined in a466350665 Smart-SSO up to 2.1.1. This affects the function Save of the file smart-sso-server/src/main/java/openjoe/smart/sso/server/controller/admin/UserController.java of the component Role Edit Page. Executing a manipulation can lead to cross site scripting. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| ERP developed by eAI Technologies has a DLL Hijacking vulnerability, allowing authenticated local attackers to place a crafted DLL file in the same directory as the program, thereby executing arbitrary code. |
| A vulnerability was detected in Cesanta Mongoose up to 7.20. This impacts the function mg_chacha20_poly1305_decrypt of the file /src/tls_chacha20.c of the component Poly1305 Authentication Tag Handler. The manipulation results in improper verification of cryptographic signature. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is said to be difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A security vulnerability has been detected in Cesanta Mongoose up to 7.20. This affects the function getpeer of the file /src/net_builtin.c of the component TCP Sequence Number Handler. The manipulation leads to improper verification of source of a communication channel. The attack may be initiated remotely. The attack's complexity is rated as high. The exploitability is reported as difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: split cached_fid bitfields to avoid shared-byte RMW races
is_open, has_lease and on_list are stored in the same bitfield byte in
struct cached_fid but are updated in different code paths that may run
concurrently. Bitfield assignments generate byte read–modify–write
operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can
restore stale values of the others.
A possible interleaving is:
CPU1: load old byte (has_lease=1, on_list=1)
CPU2: clear both flags (store 0)
CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits
To avoid this class of races, convert these flags to separate bool
fields. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio - Add spinlock protection with virtqueue notification
When VM boots with one virtio-crypto PCI device and builtin backend,
run openssl benchmark command with multiple processes, such as
openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32
openssl processes will hangup and there is error reported like this:
virtio_crypto virtio0: dataq.0:id 3 is not a head!
It seems that the data virtqueue need protection when it is handled
for virtio done notification. If the spinlock protection is added
in virtcrypto_done_task(), openssl benchmark with multiple processes
works well. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()
On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is
freed via free_transport(), which does not decrement active_num_conn,
leaking this counter.
Replace free_transport() with ksmbd_tcp_disconnect(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free
Exynos Virtual Display driver performs memory alloc/free operations
without lock protection, which easily causes concurrency problem.
For example, use-after-free can occur in race scenario like this:
```
CPU0 CPU1 CPU2
---- ---- ----
vidi_connection_ioctl()
if (vidi->connection) // true
drm_edid = drm_edid_alloc(); // alloc drm_edid
...
ctx->raw_edid = drm_edid;
...
drm_mode_getconnector()
drm_helper_probe_single_connector_modes()
vidi_get_modes()
if (ctx->raw_edid) // true
drm_edid_dup(ctx->raw_edid);
if (!drm_edid) // false
...
vidi_connection_ioctl()
if (vidi->connection) // false
drm_edid_free(ctx->raw_edid); // free drm_edid
...
drm_edid_alloc(drm_edid->edid)
kmemdup(edid); // UAF!!
...
```
To prevent these vulns, at least in vidi_context, member variables related
to memory alloc/free should be protected with ctx->lock. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add chann_lock to protect ksmbd_chann_list xarray
ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in
multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del).
Adds rw_semaphore chann_lock to struct ksmbd_session and protects
all xa_load/xa_store/xa_erase accesses. |
| In the Linux kernel, the following vulnerability has been resolved:
sched/mmcid: Don't assume CID is CPU owned on mode switch
Shinichiro reported a KASAN UAF, which is actually an out of bounds access
in the MMCID management code.
CPU0 CPU1
T1 runs in userspace
T0: fork(T4) -> Switch to per CPU CID mode
fixup() set MM_CID_TRANSIT on T1/CPU1
T4 exit()
T3 exit()
T2 exit()
T1 exit() switch to per task mode
---> Out of bounds access.
As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the
TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in
the task and drops the CID, but it does not touch the per CPU storage.
That's functionally correct because a CID is only owned by the CPU when
the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.
Now sched_mm_cid_exit() assumes that the CID is CPU owned because the
prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the
not set ONCPU bit and then invokes clear_bit() with an insanely large
bit number because TRANSIT is set (bit 29).
Prevent that by actually validating that the CID is CPU owned in
mm_drop_cid_on_cpu(). |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: fix UAF issue for file-backed mounts w/ directio option
[ 9.269940][ T3222] Call trace:
[ 9.269948][ T3222] ext4_file_read_iter+0xac/0x108
[ 9.269979][ T3222] vfs_iocb_iter_read+0xac/0x198
[ 9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180
[ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24
[ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac
[ 9.270054][ T3222] z_erofs_read_folio+0x120/0x220
[ 9.270083][ T3222] filemap_read_folio+0x60/0x120
[ 9.270102][ T3222] filemap_fault+0xcac/0x1060
[ 9.270119][ T3222] do_pte_missing+0x2d8/0x1554
[ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c
[ 9.270142][ T3222] do_page_fault+0x178/0x88c
[ 9.270167][ T3222] do_translation_fault+0x38/0x54
[ 9.270183][ T3222] do_mem_abort+0x54/0xac
[ 9.270208][ T3222] el0_da+0x44/0x7c
[ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4
[ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0
EROFS may encounter above panic when enabling file-backed mount w/
directio mount option, the root cause is it may suffer UAF in below
race condition:
- z_erofs_read_folio wq s_dio_done_wq
- z_erofs_runqueue
- erofs_fileio_submit_bio
- erofs_fileio_rq_submit
- vfs_iocb_iter_read
- ext4_file_read_iter
- ext4_dio_read_iter
- iomap_dio_rw
: bio was submitted and return -EIOCBQUEUED
- dio_aio_complete_work
- dio_complete
- dio->iocb->ki_complete (erofs_fileio_ki_complete())
- kfree(rq)
: it frees iocb, iocb.ki_filp can be UAF in file_accessed().
- file_accessed
: access NULL file point
Introduce a reference count in struct erofs_fileio_rq, and initialize it
as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will
decrease reference count, the last one decreasing the reference count
to zero will free rq. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: fix UAF in xchk_btree_check_block_owner
We cannot dereference bs->cur when trying to determine if bs->cur
aliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.
Fix this by sampling before type before any freeing could happen.
The correct temporal ordering was broken when we removed xfs_btnum_t. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly
The existing allocation of scatterlists in omap_crypto_copy_sg_lists()
was allocating an array of scatterlist pointers, not scatterlist objects,
resulting in a 4x too small allocation.
Use sizeof(*new_sg) to get the correct object size. |
| In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix use-after-free in driver_override_show()
The driver_override_show() function reads the driver_override string
without holding the device_lock. However, driver_override_store() uses
driver_set_override(), which modifies and frees the string while holding
the device_lock.
This can result in a concurrent use-after-free if the string is freed
by the store function while being read by the show function.
Fix this by holding the device_lock around the read operation. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths
The problem occurs when a signed request fails smb2 signature verification
check. In __process_request(), if check_sign_req() returns an error,
set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.
set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting
next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain
is lost. Consequently, is_chained_smb2_message() continues to point to
the same request header instead of advancing. If the header's NextCommand
field is non-zero, the function returns true, causing __handle_ksmbd_work()
to repeatedly process the same failed request in an infinite loop.
This results in the kernel log being flooded with "bad smb2 signature"
messages and high CPU usage.
This patch fixes the issue by changing the return value from
SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that
the processing loop terminates immediately rather than attempting to
continue from an invalidated offset. |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: Fix potential block overflow that cause system hang
When a user executes the FITRIM command, an underflow can occur when
calculating nblocks if end_block is too small. Since nblocks is of
type sector_t, which is u64, a negative nblocks value will become a
very large positive integer. This ultimately leads to the block layer
function __blkdev_issue_discard() taking an excessively long time to
process the bio chain, and the ns_segctor_sem lock remains held for a
long period. This prevents other tasks from acquiring the ns_segctor_sem
lock, resulting in the hang reported by syzbot in [1].
If the ending block is too small, typically if it is smaller than 4KiB
range, depending on the usage of the segment 0, it may be possible to
attempt a discard request beyond the device size causing the hang.
Exiting successfully and assign the discarded size (0 in this case)
to range->len.
Although the start and len values in the user input range are too small,
a conservative strategy is adopted here to safely ignore them, which is
equivalent to a no-op; it will not perform any trimming and will not
throw an error.
[1]
task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000
Call Trace:
rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272
nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]
nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684
[ryusuke: corrected part of the commit message about the consequences] |
