🚨 CVE-2025-27561
Unauthenticated attackers can rename "rooms" of arbitrary users.

🎖@cveNotify

🚨 CVE-2025-27565
An unauthenticated attacker can delete any user's "rooms" by knowing the user's and room IDs.

🎖@cveNotify

🚨 CVE-2025-27575
An unauthenticated attacker can obtain EV charger version and firmware upgrading history by knowing the charger ID.

🎖@cveNotify

🚨 CVE-2025-27719
Unauthenticated attackers can query an API endpoint and get device details.

🎖@cveNotify

🚨 CVE-2025-27927
An unauthenticated attackers can obtain a list of smart devices by knowing a valid username through an unprotected API.

🎖@cveNotify

🚨 CVE-2025-27929
Unauthenticated attackers can retrieve full list of users associated with arbitrary accounts.

🎖@cveNotify

🚨 CVE-2025-30257
Unauthenticated attackers can retrieve serial number of smart meters associated to a specific user account.

🎖@cveNotify

🚨 CVE-2025-30510
An attacker can upload an arbitrary file instead of a plant image.

🎖@cveNotify

🚨 CVE-2025-30512
Unauthenticated attackers can send configuration settings to device and possible perform physical actions remotely (e.g., on/off).

🎖@cveNotify

🚨 CVE-2025-31147
Unauthenticated attackers can query information about total energy consumed by EV chargers of arbitrary users.

🎖@cveNotify

🚨 CVE-2022-49957
In the Linux kernel, the following vulnerability has been resolved:

kcm: fix strp_init() order and cleanup

strp_init() is called just a few lines above this csk->sk_user_data
check, it also initializes strp->work etc., therefore, it is
unnecessary to call strp_done() to cancel the freshly initialized
work.

And if sk_user_data is already used by KCM, psock->strp should not be
touched, particularly strp->work state, so we need to move strp_init()
after the csk->sk_user_data check.

This also makes a lockdep warning reported by syzbot go away.

🎖@cveNotify

🚨 CVE-2025-40843
CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy.




CodeChecker versions up to 6.26.1 contain a buffer overflow vulnerability in the internal ldlogger library, which is executed by the CodeChecker log command.





This issue affects CodeChecker: through 6.26.1.

🎖@cveNotify

🚨 CVE-2025-63293
FairSketch Rise Ultimate Project Manager & CRM 3.9.4 is vulnerable to Insecure Permissions. A remote authenticated user can append comments or upload attachments to tickets for which they lack view or edit authorization, due to missing authorization checks in the ticketing/commenting API.

🎖@cveNotify

🚨 CVE-2020-0656
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'.

🎖@cveNotify

🚨 CVE-2024-38182
Weak authentication in Microsoft Dynamics 365 allows an unauthenticated attacker to elevate privileges over a network.

🎖@cveNotify

🚨 CVE-2025-37828
In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()

A race can occur between the MCQ completion path and the abort handler:
once a request completes, __blk_mq_free_request() sets rq->mq_hctx to
NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in
ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is
dereferenced, the kernel will crash.

Add a NULL check for the returned hwq pointer. If hwq is NULL, log an
error and return FAILED, preventing a potential NULL-pointer
dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is
removed.

This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix
ufshcd_abort_one racing issue").

This is found by our static analysis tool KNighter.

🎖@cveNotify

🚨 CVE-2016-7420
Crypto++ (aka cryptopp) through 5.6.4 does not document the requirement for a compile-time NDEBUG definition disabling the many assert calls that are unintended in production use, which might allow context-dependent attackers to obtain sensitive information by leveraging access to process memory after an assertion failure, as demonstrated by reading a core dump.

🎖@cveNotify

🚨 CVE-2025-37837
In the Linux kernel, the following vulnerability has been resolved:

iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()

Two WARNINGs are observed when SMMU driver rolls back upon failure:
arm-smmu-v3.9.auto: Failed to register iommu
arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22
------------[ cut here ]------------
WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8
Call trace:
dmam_free_coherent+0xc0/0xd8 (P)
tegra241_vintf_free_lvcmdq+0x74/0x188
tegra241_cmdqv_remove_vintf+0x60/0x148
tegra241_cmdqv_remove+0x48/0xc8
arm_smmu_impl_remove+0x28/0x60
devm_action_release+0x1c/0x40
------------[ cut here ]------------
128 pages are still in use!
WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8
Call trace:
free_contig_range+0x18c/0x1c8 (P)
cma_release+0x154/0x2f0
dma_free_contiguous+0x38/0xa0
dma_direct_free+0x10c/0x248
dma_free_attrs+0x100/0x290
dmam_free_coherent+0x78/0xd8
tegra241_vintf_free_lvcmdq+0x74/0x160
tegra241_cmdqv_remove+0x98/0x198
arm_smmu_impl_remove+0x28/0x60
devm_action_release+0x1c/0x40

This is because the LVCMDQ queue memory are managed by devres, while that
dmam_free_coherent() is called in the context of devm_action_release().

Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres
callbacks if ops->device_remove() is going to be manually freeing things
that probe allocated":
https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/

In fact, tegra241_cmdqv_init_structures() only allocates memory resources
which means any failure that it generates would be similar to -ENOMEM, so
there is no point in having that "falling back to standard SMMU" routine,
as the standard SMMU would likely fail to allocate memory too.

Remove the unwind part in tegra241_cmdqv_init_structures(), and return a
proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via
impl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since
devres will take care of that.

🎖@cveNotify

🚨 CVE-2025-38076
In the Linux kernel, the following vulnerability has been resolved:

alloc_tag: allocate percpu counters for module tags dynamically

When a module gets unloaded it checks whether any of its tags are still in
use and if so, we keep the memory containing module's allocation tags
alive until all tags are unused. However percpu counters referenced by
the tags are freed by free_module(). This will lead to UAF if the memory
allocated by a module is accessed after module was unloaded.

To fix this we allocate percpu counters for module allocation tags
dynamically and we keep it alive for tags which are still in use after
module unloading. This also removes the requirement of a larger
PERCPU_MODULE_RESERVE when memory allocation profiling is enabled because
percpu memory for counters does not need to be reserved anymore.

🎖@cveNotify

🚨 CVE-2025-38080
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Increase block_sequence array size

[Why]
It's possible to generate more than 50 steps in hwss_build_fast_sequence,
for example with a 6-pipe asic where all pipes are in one MPC chain. This
overflows the block_sequence buffer and corrupts block_sequence_steps,
causing a crash.

[How]
Expand block_sequence to 100 items. A naive upper bound on the possible
number of steps for a 6-pipe asic, ignoring the potential for steps to be
mutually exclusive, is 91 with current code, therefore 100 is sufficient.

🎖@cveNotify

🚨 CVE-2025-38081
In the Linux kernel, the following vulnerability has been resolved:

spi-rockchip: Fix register out of bounds access

Do not write native chip select stuff for GPIO chip selects.
GPIOs can be numbered much higher than native CS.
Also, it makes no sense.

🎖@cveNotify