| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Inappropriate implementation in DevTools in Google Chrome prior to 136.0.7103.59 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) |
| A vulnerability was determined in codesiddhant Jasmin Ransomware up to 1.0.1. This vulnerability affects unknown code of the file /handshake.php. This manipulation of the argument machine_name/computer_user/os/date/time/ip/location/systemid/password causes sql injection. The attack can be initiated remotely. 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. |
| A weakness has been identified in mtons mblog up to 3.5.0. This issue affects some unknown processing of the file /admin/role/list. This manipulation of the argument Name causes cross site scripting. The attack may be initiated remotely. The exploit has been made available to the public and could be exploited. |
| A maliciously crafted CATPART file, when parsed in CC5Dll.dll and ASMBASE228A.dll through Autodesk AutoCAD, may force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: virtuser: fix potential out-of-bound write
If the caller wrote more characters, count is truncated to the max
available space in "simple_write_to_buffer". Check that the input
size does not exceed the buffer size. Write a zero termination
afterwards. |
| A cross-site scripting (XSS) vulnerability has been reported to affect QuLog Center. If a remote attacker gains an administrator account, they can then exploit the vulnerability to bypass security mechanisms or read application data.
We have already fixed the vulnerability in the following version:
QuLog Center 1.8.2.923 ( 2025/08/27 ) and later |
| A cross-site scripting (XSS) vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to bypass security mechanisms or read application data.
We have already fixed the vulnerability in the following version:
File Station 5 5.5.6.5018 and later |
| An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version:
File Station 5 5.5.6.5018 and later |
| An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains an administrator account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version:
File Station 5 5.5.6.5018 and later |
| An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version:
File Station 5 5.5.6.5018 and later |
| An allocation of resources without limits or throttling vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to prevent other systems, applications, or processes from accessing the same type of resource.
We have already fixed the vulnerability in the following version:
File Station 5 5.5.6.5018 and later |
| A cross site scripting vulnerability exists when Microsoft Dynamics 365 (on-premises) does not properly sanitize a specially crafted web request to an affected Dynamics server, aka 'Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability'. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: fix memory corruption on probe
Add the missing sanity check on the probed-session count to avoid
corrupting memory beyond the fixed-size slab-allocated session array
when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
devicetree. |
| A vulnerability was found in 70mai X200 up to 20251019. This issue affects some unknown processing of the component Init Script Handler. The manipulation results in file inclusion. The attack requires a local approach. A high complexity level is associated with this attack. The exploitability is assessed as difficult. 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. |
| Due to lack of server-side input validation, attackers can inject malicious JavaScript code into users personal spaces of the web portal. |
| Stored Cross Site Scripting (XSS) vulnerability in Smart School 7.0 due to lack of proper validation of user input when sending a POST request to '/online_admission', wich affects the parameters 'firstname', 'lastname', 'guardian_name' and others. This vulnerability could allow a remote user to send a specially crafted query to an authenticated user and steal his/her session cookie details. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Use is_kdump_kernel() to check for kdump
The smartpqi driver checks the reset_devices variable to determine
whether special adjustments need to be made for kdump. This has the
effect that after a regular kexec reboot, some driver parameters such as
max_transfer_size are much lower than usual. More importantly, kexec
reboot tests have revealed memory corruption caused by the driver log
being written to system memory after a kexec.
Fix this by testing is_kdump_kernel() rather than reset_devices where
appropriate. |
| A vulnerability, which was classified as critical, was found in codesiddhant Jasmin Ransomware 1.0.1. Affected is an unknown function of the file /checklogin.php. The manipulation of the argument username/password leads to sql injection. It is possible to launch the attack remotely. 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 vulnerability has been found in codesiddhant Jasmin Ransomware up to 1.0.1 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /dashboard.php. The manipulation of the argument Search leads to sql injection. The attack can be launched remotely. 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. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix space cache corruption and potential double allocations
When testing space_cache v2 on a large set of machines, we encountered a
few symptoms:
1. "unable to add free space :-17" (EEXIST) errors.
2. Missing free space info items, sometimes caught with a "missing free
space info for X" error.
3. Double-accounted space: ranges that were allocated in the extent tree
and also marked as free in the free space tree, ranges that were
marked as allocated twice in the extent tree, or ranges that were
marked as free twice in the free space tree. If the latter made it
onto disk, the next reboot would hit the BUG_ON() in
add_new_free_space().
4. On some hosts with no on-disk corruption or error messages, the
in-memory space cache (dumped with drgn) disagreed with the free
space tree.
All of these symptoms have the same underlying cause: a race between
caching the free space for a block group and returning free space to the
in-memory space cache for pinned extents causes us to double-add a free
range to the space cache. This race exists when free space is cached
from the free space tree (space_cache=v2) or the extent tree
(nospace_cache, or space_cache=v1 if the cache needs to be regenerated).
struct btrfs_block_group::last_byte_to_unpin and struct
btrfs_block_group::progress are supposed to protect against this race,
but commit d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when
waiting for a transaction commit") subtly broke this by allowing
multiple transactions to be unpinning extents at the same time.
Specifically, the race is as follows:
1. An extent is deleted from an uncached block group in transaction A.
2. btrfs_commit_transaction() is called for transaction A.
3. btrfs_run_delayed_refs() -> __btrfs_free_extent() runs the delayed
ref for the deleted extent.
4. __btrfs_free_extent() -> do_free_extent_accounting() ->
add_to_free_space_tree() adds the deleted extent back to the free
space tree.
5. do_free_extent_accounting() -> btrfs_update_block_group() ->
btrfs_cache_block_group() queues up the block group to get cached.
block_group->progress is set to block_group->start.
6. btrfs_commit_transaction() for transaction A calls
switch_commit_roots(). It sets block_group->last_byte_to_unpin to
block_group->progress, which is block_group->start because the block
group hasn't been cached yet.
7. The caching thread gets to our block group. Since the commit roots
were already switched, load_free_space_tree() sees the deleted extent
as free and adds it to the space cache. It finishes caching and sets
block_group->progress to U64_MAX.
8. btrfs_commit_transaction() advances transaction A to
TRANS_STATE_SUPER_COMMITTED.
9. fsync calls btrfs_commit_transaction() for transaction B. Since
transaction A is already in TRANS_STATE_SUPER_COMMITTED and the
commit is for fsync, it advances.
10. btrfs_commit_transaction() for transaction B calls
switch_commit_roots(). This time, the block group has already been
cached, so it sets block_group->last_byte_to_unpin to U64_MAX.
11. btrfs_commit_transaction() for transaction A calls
btrfs_finish_extent_commit(), which calls unpin_extent_range() for
the deleted extent. It sees last_byte_to_unpin set to U64_MAX (by
transaction B!), so it adds the deleted extent to the space cache
again!
This explains all of our symptoms above:
* If the sequence of events is exactly as described above, when the free
space is re-added in step 11, it will fail with EEXIST.
* If another thread reallocates the deleted extent in between steps 7
and 11, then step 11 will silently re-add that space to the space
cache as free even though it is actually allocated. Then, if that
space is allocated *again*, the free space tree will be corrupted
(namely, the wrong item will be deleted).
* If we don't catch this free space tree corr
---truncated--- |
