| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Harden userspace-supplied xdp_desc validation
Turned out certain clearly invalid values passed in xdp_desc from
userspace can pass xp_{,un}aligned_validate_desc() and then lead
to UBs or just invalid frames to be queued for xmit.
desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len
can cause positive integer overflow and wraparound, the same way low
enough desc->addr with a non-zero pool->tx_metadata_len can cause
negative integer overflow. Both scenarios can then pass the
validation successfully.
This doesn't happen with valid XSk applications, but can be used
to perform attacks.
Always promote desc->len to ``u64`` first to exclude positive
overflows of it. Use explicit check_{add,sub}_overflow() when
validating desc->addr (which is ``u64`` already).
bloat-o-meter reports a little growth of the code size:
add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)
Function old new delta
xskq_cons_peek_desc 299 330 +31
xsk_tx_peek_release_desc_batch 973 1002 +29
xsk_generic_xmit 3148 3132 -16
but hopefully this doesn't hurt the performance much. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: debugfs: Fix legacy mode page table dump logic
In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR
maybe uninitialized or zero in that case and may cause oops like:
Oops: general protection fault, probably for non-canonical address
0xf00087d3f000f000: 0000 [#1] SMP NOPTI
CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014
RIP: 0010:pgtable_walk_level+0x98/0x150
RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206
RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e
RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000
RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000
R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98
FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0
PKRU: 55555554
Call Trace:
<TASK>
pgtable_walk_level+0x88/0x150
domain_translation_struct_show.isra.0+0x2d9/0x300
dev_domain_translation_struct_show+0x20/0x40
seq_read_iter+0x12d/0x490
...
Avoid walking the page table if TT is not 00b or 01b. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: avoid soft lockup when mprotect to large memory area
When calling mprotect() to a large hugetlb memory area in our customer's
workload (~300GB hugetlb memory), soft lockup was observed:
watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]
CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7
Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mte_clear_page_tags+0x14/0x24
lr : mte_sync_tags+0x1c0/0x240
sp : ffff80003150bb80
x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000
x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458
x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000
x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000
x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000
Call trace:
mte_clear_page_tags+0x14/0x24
set_huge_pte_at+0x25c/0x280
hugetlb_change_protection+0x220/0x430
change_protection+0x5c/0x8c
mprotect_fixup+0x10c/0x294
do_mprotect_pkey.constprop.0+0x2e0/0x3d4
__arm64_sys_mprotect+0x24/0x44
invoke_syscall+0x50/0x160
el0_svc_common+0x48/0x144
do_el0_svc+0x30/0xe0
el0_svc+0x30/0xf0
el0t_64_sync_handler+0xc4/0x148
el0t_64_sync+0x1a4/0x1a8
Soft lockup is not triggered with THP or base page because there is
cond_resched() called for each PMD size.
Although the soft lockup was triggered by MTE, it should be not MTE
specific. The other processing which takes long time in the loop may
trigger soft lockup too.
So add cond_resched() for hugetlb to avoid soft lockup. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()
syzbot reported a f2fs bug as below:
Oops: gen[ 107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G W 6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)}
RIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284
Call Trace:
<TASK>
f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]
f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436
__f2fs_remount fs/f2fs/super.c:2653 [inline]
f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297
reconfigure_super+0x224/0x890 fs/super.c:1077
do_remount fs/namespace.c:3314 [inline]
path_mount+0xd18/0xfe0 fs/namespace.c:4112
do_mount fs/namespace.c:4133 [inline]
__do_sys_mount fs/namespace.c:4344 [inline]
__se_sys_mount+0x317/0x410 fs/namespace.c:4321
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref
issue in strcmp().
The bug can be reproduced w/ below scripts:
mkfs.f2fs -f /dev/vdb
mount -t f2fs -o usrquota /dev/vdb /mnt/f2fs
quotacheck -uc /mnt/f2fs/
umount /mnt/f2fs
mount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs
mount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs
umount /mnt/f2fs
So, before old_qname and new_qname comparison, we need to check whether
they are all valid pointers, fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix data race in CPU latency PM QoS request handling
The cpu_latency_qos_add/remove/update_request interfaces lack internal
synchronization by design, requiring the caller to ensure thread safety.
The current implementation relies on the 'pm_qos_enabled' flag, which is
insufficient to prevent concurrent access and cannot serve as a proper
synchronization mechanism. This has led to data races and list
corruption issues.
A typical race condition call trace is:
[Thread A]
ufshcd_pm_qos_exit()
--> cpu_latency_qos_remove_request()
--> cpu_latency_qos_apply();
--> pm_qos_update_target()
--> plist_del <--(1) delete plist node
--> memset(req, 0, sizeof(*req));
--> hba->pm_qos_enabled = false;
[Thread B]
ufshcd_devfreq_target
--> ufshcd_devfreq_scale
--> ufshcd_scale_clks
--> ufshcd_pm_qos_update <--(2) pm_qos_enabled is true
--> cpu_latency_qos_update_request
--> pm_qos_update_target
--> plist_del <--(3) plist node use-after-free
Introduces a dedicated mutex to serialize PM QoS operations, preventing
data races and ensuring safe access to PM QoS resources, including sysfs
interface reads. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential null deref in ext4_mb_init()
In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called
when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo
slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()
lacks null pointer checking, this leads to a null pointer dereference.
==================================================================
EXT4-fs: no memory for groupinfo slab cache
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0002 [#1] SMP PTI
CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)
RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40
Call Trace:
<TASK>
xa_destroy+0x61/0x130
ext4_mb_init+0x483/0x540
__ext4_fill_super+0x116d/0x17b0
ext4_fill_super+0xd3/0x280
get_tree_bdev_flags+0x132/0x1d0
vfs_get_tree+0x29/0xd0
do_new_mount+0x197/0x300
__x64_sys_mount+0x116/0x150
do_syscall_64+0x50/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
==================================================================
Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()
to prevent this issue. The same fix is also applied to
ext4_mb_largest_free_orders_destroy(). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod
Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when
device is gone") UBSAN reports:
UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17
index 28 is out of range for type 'pm8001_phy [16]'
on rmmod when using an expander.
For a direct attached device, attached_phy contains the local phy id.
For a device behind an expander, attached_phy contains the remote phy
id, not the local phy id.
I.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a
device behind an expander, attached_phy can be much larger than
pm8001_ha->chip->n_phy (depending on the amount of phys of the
expander).
E.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the
ports has an expander connected. The expander has 31 phys with phy ids
0-30.
The pm8001_ha->phy array only contains the phys of the HBA. It does not
contain the phys of the expander. Thus, it is wrong to use attached_phy
to index the pm8001_ha->phy array for a device behind an expander.
Thus, we can only clear phy_attached for devices that are directly
attached. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix race in do_task() when draining
When do_task() exhausts its iteration budget (!ret), it sets the state
to TASK_STATE_IDLE to reschedule, without a secondary check on the
current task->state. This can overwrite the TASK_STATE_DRAINING state
set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().
While state changes are protected by a spinlock, both rxe_cleanup_task()
and rxe_disable_task() release the lock while waiting for the task to
finish draining in the while(!is_done(task)) loop. The race occurs if
do_task() hits its iteration limit and acquires the lock in this window.
The cleanup logic may then proceed while the task incorrectly
reschedules itself, leading to a potential use-after-free.
This bug was introduced during the migration from tasklets to workqueues,
where the special handling for the draining case was lost.
Fix this by restoring the original pre-migration behavior. If the state is
TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to
force a new loop iteration. This allows the task to finish its work, so
that a subsequent iteration can reach the switch statement and correctly
transition the state to TASK_STATE_DRAINED, stopping the task as intended. |
| A security vulnerability has been detected in ZrLog up to 3.1.5. This vulnerability affects unknown code of the file /api/admin/template/config of the component Theme Configuration Form. Such manipulation of the argument footerLink leads to cross site scripting. The attack may be launched remotely. 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. |
| A vulnerability classified as problematic was found in ZCMS 3.6.0. This vulnerability affects unknown code of the component Create Article Page. The manipulation of the argument Title leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in rowboatlabs rowboat up to 8096eaf63b5a0732edd8f812bee05b78e214ee97. It has been rated as critical. Affected by this issue is the function PUT of the file apps/rowboat/app/api/uploads/[fileId]/route.ts of the component Session Handler. The manipulation of the argument params leads to missing authentication. The attack may be launched remotely. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. It is expected that this issue will be fixed in the near future. |
| This vulnerability exists in Digisol DG-GR6821AC Router due to misconfiguration of both Secure and HttpOnly flags on session cookies associated with the router web interface. A remote attacker could exploit this vulnerability by capturing the session cookies transmitted over an unsecure HTTP connection.
Successful exploitation of this vulnerability could allow the attacker to obtain sensitive information from the targeted device. |
| This vulnerability exists in Digisol DG-GR6821AC Router due to cleartext transmission of credentials in its web management interface. A remote attacker could exploit this vulnerability by intercepting the network traffic and capturing cleartext credentials.
Successful exploitation of this vulnerability could allow the attacker to gain unauthorized access to the targeted device. |
| A vulnerability classified as critical was found in risesoft-y9 Digital-Infrastructure up to 9.6.7. Affected by this vulnerability is the function deleteFile of the file /Digital-Infrastructure-9.6.7/y9-digitalbase-webapp/y9-module-filemanager/risenet-y9boot-webapp-filemanager/src/main/java/net/risesoft/y9public/controller/Y9FileController.java. The manipulation of the argument fullPath leads to path traversal. 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. |
| The parisneo/lollms repository is affected by a timing attack vulnerability in the `authenticate_user` function within the `lollms_authentication.py` file. This vulnerability allows attackers to enumerate valid usernames and guess passwords incrementally by analyzing response time differences. The affected version is the latest, and the issue is resolved in version 20.1. The vulnerability arises from the use of Python's default string equality operator for password comparison, which compares characters sequentially and exits on the first mismatch, leading to variable response times based on the number of matching initial characters. |
| Dependency-Track is a component analysis platform that allows organizations to identify and reduce risk in the software supply chain. Prior to version 4.13.5, Dependency-Track may send credentials meant for a private NuGet repository to `api.nuget.org` via the HTTP `Authorization` header, and may disclose names and versions of components marked as internal to `api.nuget.org`. This can happen if the Dependency-Track instance contains .NET components, a custom NuGet repository has been configured, the custom repository has been configured with authentication credentials, and the repository server does not provide `PackageBaseAddress` resource in its service index. The issue has been fixed in Dependency-Track 4.13.5. Some workarounds are avaialble. Disable custom NuGet repositories until the patch has been applied, invalidate the previously used credentials, and generate new credentials for usage after the patch has been applied. |
| get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2. |
| LSTM-Kirigaya's openmcp-client is a vscode plugin for mcp developer. Prior to version 0.1.12, when users on a Windows platform connect to an attacker controlled MCP server, attackers could provision a malicious authorization server endpoint to silently achieve an OS command injection attack in the open() invocation, leading to client system compromise. This issue has been patched in version 0.1.12. |
| OpenEBS Local PV RawFile allows dynamic deployment of Stateful Persistent Node-Local Volumes & Filesystems for Kubernetes. Prior to version 0.10.0, persistent volume data is world readable and that would allow non-privileged users to access sensitive data such as databases of k8s workload. The rawfile-localpv storage class creates persistent volume data under /var/csi/rawfile/ on Kubernetes hosts by default. However, the directory and data in it are world-readable. It allows non-privileged users to access the whole persistent volume data, and those can include sensitive information such as a whole database if the Kubernetes tenants are running MySQL or PostgreSQL in a container so it could lead to a database breach. This issue has been patched in version 0.10.0. |
| Valtimo is a platform for Business Process Automation. In versions before 12.16.0.RELEASE, and from 13.0.0.RELEASE to before 13.1.2.RELEASE, any admin that can create or modify and execute process-definitions could gain access to sensitive data or resources. This includes but is not limited to: running executables on the application host, inspecting and extracting data from the host environment or application properties, spring beans (application context, database pooling). The following conditions have to be met in order to perform this attack: the user must be logged in, have the admin role, and must have some knowledge about running scripts via a the Camunda/Operator engine. Version 12.16.0 and 13.1.2 have been patched. It is strongly advised to upgrade. If no scripting is needed in any of the processes, it could be possible to disable it altogether via the ProcessEngineConfiguration. However, this workaround could lead to unexpected side-effects. |
