CVE ID : CVE-2025-44885
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the remote_ip parameter in the web_snmpv3_remote_engineId_add_post function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44886
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the byruleEditName parameter in the web_acl_mgmt_Rules_Edit_postcontains function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44888
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the stp_conf_name parameter in the web_stp_globalSetting_post function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44887
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the radIpkey parameter in the web_radiusSrv_post function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44890
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the host_ip parameter in the web_snmp_notifyv3_add_post function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44893
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : FW-WGS-804HPT v1.305b241111 was discovered to contain a stack overflow via the ruleNamekey parameter in the web_acl_mgmt_Rules_Apply_post function.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-4997
Published : May 20, 2025, 8:15 p.m. | 22 minutes ago
Description : A vulnerability, which was classified as problematic, was found in H3C R2+ProG up to 200R004. Affected is the function UpdateWanParams/AddMacList/EditMacList/AddWlanMacList/EditWlanMacList/Edit_BasicSSID/Edit_GuestSSIDFor2P4G/Edit_BasicSSID_5G/SetAPInfoById of the file /goform/aspForm of the component HTTP POST Request Handler. The manipulation of the argument param leads to denial of service. 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.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-48017
Published : May 20, 2025, 4:15 p.m. | 3 hours, 44 minutes ago
Description : Improper limitation of pathname in Circuit Provisioning and File Import applications allows modification and uploading of files
Severity: 9.0 | CRITICAL
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37981
Published : May 20, 2025, 5:15 p.m. | 1 hour, 34 minutes ago
Description : 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.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37982
Published : May 20, 2025, 5:15 p.m. | 1 hour, 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
wifi: wl1251: fix memory leak in wl1251_tx_work
The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails
with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37980
Published : May 20, 2025, 5:15 p.m. | 1 hour, 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
block: fix resource leak in blk_register_queue() error path
When registering a queue fails after blk_mq_sysfs_register() is
successful but the function later encounters an error, we need
to clean up the blk_mq_sysfs resources.
Add the missing blk_mq_sysfs_unregister() call in the error path
to properly clean up these resources and prevent a memory leak.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37979
Published : May 20, 2025, 5:15 p.m. | 1 hour, 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix sc7280 lpass potential buffer overflow
Case values introduced in commit
5f78e1fb7a3e (“ASoC: qcom: Add driver support for audioreach solution”)
cause out of bounds access in arrays of sc7280 driver data (e.g. in case
of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).
Redefine LPASS_MAX_PORTS to consider the maximum possible port id for
q6dsp as sc7280 driver utilizes some of those values.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-44084
Published : May 20, 2025, 5:15 p.m. | 1 hour, 34 minutes ago
Description : D-link DI-8100 16.07.26A1 is vulnerable to Command Injection. An attacker can exploit this vulnerability by crafting specific HTTP requests, triggering the command execution flaw and gaining the highest privilege shell access to the firmware system.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-22157
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : This High severity PrivEsc (Privilege Escalation) vulnerability was introduced in versions:
9.12.0, 10.3.0, 10.4.0, and 10.5.0 of Jira Core Data Center and Server
5.12.0, 10.3.0, 10.4.0, and 10.5.0 of Jira Service Management Data Center and Server
This PrivEsc (Privilege Escalation) vulnerability, with a CVSS Score of 7.2, allows an attacker to perform actions as a higher-privileged user.
Atlassian recommends that Jira Core Data Center and Server and Jira Service Management Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:
Jira Core Data Center and Server 9.12: Upgrade to a release greater than or equal to 9.12.20
Jira Service Management Data Center and Server 5.12: Upgrade to a release greater than or equal to 5.12.20
Jira Core Data Center 10.3: Upgrade to a release greater than or equal to 10.3.5
Jira Service Management Data Center 10.3: Upgrade to a release greater than or equal to 10.3.5
Jira Core Data Center 10.4: Upgrade to a release greater than or equal to 10.6.0
Jira Service Management Data Center 10.4: Upgrade to a release greater than or equal to 10.6.0
Jira Core Data Center 10.5: Upgrade to a release greater than or equal to 10.5.1
Jira Service Management Data Center 10.5: Upgrade to a release greater than or equal to 10.5.1
See the release notes. You can download the latest version of Jira Core Data Center and Jira Service Management Data Center from the download center.
This vulnerability was reported via our Atlassian (Internal) program.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37986
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
usb: typec: class: Invalidate USB device pointers on partner unregistration
To avoid using invalid USB device pointers after a Type-C partner
disconnects, this patch clears the pointers upon partner unregistration.
This ensures a clean state for future connections.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37984
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdsa – Harden against integer overflows in DIV_ROUND_UP()
Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa
implementation’s ->key_size() callback returns an unusually large value.
Herbert instead suggests (for a division by 8):
X / 8 + !!(X & 7)
Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and
use it in lieu of DIV_ROUND_UP() for ->key_size() return values.
Additionally, use the macro in ecc_digits_from_bytes(), whose “nbytes”
parameter is a ->key_size() return value in some instances, or a
user-specified ASN.1 length in the case of ecdsa_get_signature_rs().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37987
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
pds_core: Prevent possible adminq overflow/stuck condition
The pds_core’s adminq is protected by the adminq_lock, which prevents
more than 1 command to be posted onto it at any one time. This makes it
so the client drivers cannot simultaneously post adminq commands.
However, the completions happen in a different context, which means
multiple adminq commands can be posted sequentially and all waiting
on completion.
On the FW side, the backing adminq request queue is only 16 entries
long and the retry mechanism and/or overflow/stuck prevention is
lacking. This can cause the adminq to get stuck, so commands are no
longer processed and completions are no longer sent by the FW.
As an initial fix, prevent more than 16 outstanding adminq commands so
there’s no way to cause the adminq from getting stuck. This works
because the backing adminq request queue will never have more than 16
pending adminq commands, so it will never overflow. This is done by
reducing the adminq depth to 16.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37988
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
fix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()
Normally do_lock_mount(path, _) is locking a mountpoint pinned by
*path and at the time when matching unlock_mount() unlocks that
location it is still pinned by the same thing.
Unfortunately, for ‘beneath’ case it’s no longer that simple –
the object being locked is not the one *path points to. It’s the
mountpoint of path->mnt. The thing is, without sufficient locking
->mnt_parent may change under us and none of the locks are held
at that point. The rules are
* mount_lock stabilizes m->mnt_parent for any mount m.
* namespace_sem stabilizes m->mnt_parent, provided that
m is mounted.
* if either of the above holds and refcount of m is positive,
we are guaranteed the same for refcount of m->mnt_parent.
namespace_sem nests inside inode_lock(), so do_lock_mount() has
to take inode_lock() before grabbing namespace_sem. It does
recheck that path->mnt is still mounted in the same place after
getting namespace_sem, and it does take care to pin the dentry.
It is needed, since otherwise we might end up with racing mount –move
(or umount) happening while we were getting locks; in that case
dentry would no longer be a mountpoint and could’ve been evicted
on memory pressure along with its inode – not something you want
when grabbing lock on that inode.
However, pinning a dentry is not enough – the matching mount is
also pinned only by the fact that path->mnt is mounted on top it
and at that point we are not holding any locks whatsoever, so
the same kind of races could end up with all references to
that mount gone just as we are about to enter inode_lock().
If that happens, we are left with filesystem being shut down while
we are holding a dentry reference on it; results are not pretty.
What we need to do is grab both dentry and mount at the same time;
that makes inode_lock() safe *and* avoids the problem with fs getting
shut down under us. After taking namespace_sem we verify that
path->mnt is still mounted (which stabilizes its ->mnt_parent) and
check that it’s still mounted at the same place. From that point
on to the matching namespace_unlock() we are guaranteed that
mount/dentry pair we’d grabbed are also pinned by being the mountpoint
of path->mnt, so we can quietly drop both the dentry reference (as
the current code does) and mnt one – it’s OK to do under namespace_sem,
since we are not dropping the final refs.
That solves the problem on do_lock_mount() side; unlock_mount()
also has one, since dentry is guaranteed to stay pinned only until
the namespace_unlock(). That’s easy to fix – just have inode_unlock()
done earlier, while it’s still pinned by mp->m_dentry.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37983
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
qibfs: fix _another_ leak
failure to allocate inode => leaked dentry…
this one had been there since the initial merge; to be fair,
if we are that far OOM, the odds of failing at that particular
allocation are low…
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…
CVE ID : CVE-2025-37991
Published : May 20, 2025, 6:15 p.m. | 34 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with
a second SIGFPE in the signal handler. Dave analyzed it, and it happens
because glibc uses a double-word floating-point store to atomically update
function descriptors. As a result of lazy binding, we hit a floating-point
store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the
co-processor encounters *any* floating-point instruction except for a double
store of register %fr0. The latter cancels all pending traps. Let’s fix this
by clearing the Trap (T) bit in the FP status register before returning to the
signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t *i, void *v) {
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGFPE);
sigprocmask(SIG_UNBLOCK, &set, NULL);
printf(“GOT signal %d with si_code %ldn”, sig, i->si_code);
}
int main() {
struct sigaction action = {
.sa_sigaction = fpe_func,
.sa_flags = SA_RESTART|SA_SIGINFO };
sigaction(SIGFPE, &action, 0);
feenableexcept(FE_OVERFLOW);
return printf(“%lfn”,1.7976931348623158E308*1.7976931348623158E308);
}
root@parisc:~# gcc fpe.c -lm
root@parisc:~# ./a.out
Floating point exception
root@parisc:~# strace -f ./a.out
execve(“./a.out”, [“./a.out”], 0xf9ac7034 /* 20 vars */) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
…
rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
— SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} —
— SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} —
+++ killed by SIGFPE +++
Floating point exception
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more…