| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)
According to UFS specifications, the power-off sequence for a UFS device
includes:
- Sending an SSU command with Power_Condition=3 and await a response.
- Asserting RST_N low.
- Turning off REF_CLK.
- Turning off VCC.
- Turning off VCCQ/VCCQ2.
As part of ufs shutdown, after the SSU command completion, asserting
hardware reset (HWRST) triggers the device firmware to wake up and
execute its reset routine. This routine initializes hardware blocks and
takes a few milliseconds to complete. During this time, the ICCQ draws a
large current.
This large ICCQ current may cause issues for the regulator which is
supplying power to UFS, because the turn off request from UFS driver to
the regulator framework will be immediately followed by low power
mode(LPM) request by regulator framework. This is done by framework
because UFS which is the only client is requesting for disable. So if
the rail is still in the process of shutting down while ICCQ exceeds LPM
current thresholds, and LPM mode is activated in hardware during this
state, it may trigger an overcurrent protection (OCP) fault in the
regulator.
To prevent this, a 10ms delay is added after asserting HWRST. This
allows the reset operation to complete while power rails remain active
and in high-power mode.
Currently there is no way for Host to query whether the reset is
completed or not and hence this the delay is based on experiments with
Qualcomm UFS controllers across multiple UFS vendors. |
| EduSoho versions prior to 22.4.7 contain an arbitrary file read vulnerability in the classroom-course-statistics export functionality. A remote, unauthenticated attacker can supply crafted path traversal sequences in the fileNames[] parameter to read arbitrary files from the server filesystem, including application configuration files such as config/parameters.yml that may contain secrets and database credentials. Exploitation evidence was observed by the Shadowserver Foundation on 2026-01-19 (UTC). |
| All versions of the package ggit are vulnerable to Arbitrary Argument Injection via the clone() API, which allows specifying the remote URL to clone and the file on disk to clone to. The library does not sanitize for user input or validate a given URL scheme, nor does it properly pass command-line flags to the git binary using the double-dash POSIX characters (--) to communicate the end of options. |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: avoid having an active sc_timer before freeing sci
Because kthread_stop did not stop sc_task properly and returned -EINTR,
the sc_timer was not properly closed, ultimately causing the problem [1]
reported by syzbot when freeing sci due to the sc_timer not being closed.
Because the thread sc_task main function nilfs_segctor_thread() returns 0
when it succeeds, when the return value of kthread_stop() is not 0 in
nilfs_segctor_destroy(), we believe that it has not properly closed
sc_timer.
We use timer_shutdown_sync() to sync wait for sc_timer to shutdown, and
set the value of sc_task to NULL under the protection of lock
sc_state_lock, so as to avoid the issue caused by sc_timer not being
properly shutdowned.
[1]
ODEBUG: free active (active state 0) object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout
Call trace:
nilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline]
nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c:2877
nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509 |
| A flaw exists whereby a user can make a specific call to a FlashArray endpoint allowing privilege escalation. |
| The
“socket” module provides a pure-Python fallback to the
socket.socketpair() function for platforms that don’t support AF_UNIX,
such as Windows. This pure-Python implementation uses AF_INET or
AF_INET6 to create a local connected pair of sockets. The connection
between the two sockets was not verified before passing the two sockets
back to the user, which leaves the server socket vulnerable to a
connection race from a malicious local peer.
Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included. |
| In the Linux kernel, the following vulnerability has been resolved:
net: netpoll: fix incorrect refcount handling causing incorrect cleanup
commit efa95b01da18 ("netpoll: fix use after free") incorrectly
ignored the refcount and prematurely set dev->npinfo to NULL during
netpoll cleanup, leading to improper behavior and memory leaks.
Scenario causing lack of proper cleanup:
1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is
allocated, and refcnt = 1
- Keep in mind that npinfo is shared among all netpoll instances. In
this case, there is just one.
2) Another netpoll is also associated with the same NIC and
npinfo->refcnt += 1.
- Now dev->npinfo->refcnt = 2;
- There is just one npinfo associated to the netdev.
3) When the first netpolls goes to clean up:
- The first cleanup succeeds and clears np->dev->npinfo, ignoring
refcnt.
- It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`
- Set dev->npinfo = NULL, without proper cleanup
- No ->ndo_netpoll_cleanup() is either called
4) Now the second target tries to clean up
- The second cleanup fails because np->dev->npinfo is already NULL.
* In this case, ops->ndo_netpoll_cleanup() was never called, and
the skb pool is not cleaned as well (for the second netpoll
instance)
- This leaks npinfo and skbpool skbs, which is clearly reported by
kmemleak.
Revert commit efa95b01da18 ("netpoll: fix use after free") and adds
clarifying comments emphasizing that npinfo cleanup should only happen
once the refcount reaches zero, ensuring stable and correct netpoll
behavior. |
| In the Linux kernel, the following vulnerability has been resolved:
vmw_balloon: indicate success when effectively deflating during migration
When migrating a balloon page, we first deflate the old page to then
inflate the new page.
However, if inflating the new page succeeded, we effectively deflated the
old page, reducing the balloon size.
In that case, the migration actually worked: similar to migrating+
immediately deflating the new page. The old page will be freed back to
the buddy.
Right now, the core will leave the page be marked as isolated (as we
returned an error). When later trying to putback that page, we will run
into the WARN_ON_ONCE() in balloon_page_putback().
That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:
stop using __ClearPageMovable()"); before that change, we would have
tolerated that way of handling it.
To fix it, let's just return 0 in that case, making the core effectively
just clear the "isolated" flag + freeing it back to the buddy as if the
migration succeeded. Note that the new page will also get freed when the
core puts the last reference.
Note that this also makes it all be more consistent: we will no longer
unisolate the page in the balloon driver while keeping it marked as being
isolated in migration core.
This was found by code inspection. |
| A possible buffer overflow in selected cameras' drivers from XProtect Device Pack can allow an attacker with access to internal network to execute commands on Recording Server under strict conditions. |
| An arbitrary file read vulnerability in Adguard Home before v0.107.52 allows authenticated attackers to access arbitrary files as root on the underlying Operating System via placing a crafted file into a readable directory. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: check device's attached status in compat ioctls
Syzbot identified an issue [1] that crashes kernel, seemingly due to
unexistent callback dev->get_valid_routes(). By all means, this should
not occur as said callback must always be set to
get_zero_valid_routes() in __comedi_device_postconfig().
As the crash seems to appear exclusively in i386 kernels, at least,
judging from [1] reports, the blame lies with compat versions
of standard IOCTL handlers. Several of them are modified and
do not use comedi_unlocked_ioctl(). While functionality of these
ioctls essentially copy their original versions, they do not
have required sanity check for device's attached status. This,
in turn, leads to a possibility of calling select IOCTLs on a
device that has not been properly setup, even via COMEDI_DEVCONFIG.
Doing so on unconfigured devices means that several crucial steps
are missed, for instance, specifying dev->get_valid_routes()
callback.
Fix this somewhat crudely by ensuring device's attached status before
performing any ioctls, improving logic consistency between modern
and compat functions.
[1] Syzbot report:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0
Call Trace:
<TASK>
get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]
parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401
do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594
compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]
comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273
__do_compat_sys_ioctl fs/ioctl.c:695 [inline]
__se_compat_sys_ioctl fs/ioctl.c:638 [inline]
__ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
... |
| Improper access control in the endpoint /RoleMenuMapping/AddRoleMenu of Digiteam v4.21.0.0 allows authenticated attackers to escalate privileges. |
| A stack buffer overflow vulnerability has been identified in certain router models. An authenticated attacker may trigger this vulnerability by sending a crafted request, potentially impacting the availability of the device.
Refer to the ' Security Update for ASUS Router Firmware' section on the ASUS Security Advisory for more information. |
| An authentication-bypass vulnerability exists in AiCloud. This vulnerability can be triggered by an unintended side effect of the Samba functionality, potentially leading to allow execution of specific functions without proper authorization.
Refer to the Security Update for ASUS Router Firmware section on the ASUS Security Advisory for more information. |
| An integer underflow vulnerability has been identified in Aicloud. An authenticated attacker may trigger this vulnerability by sending a crafted request, potentially impacting the availability of the device.
Refer to the ' Security Update for ASUS Router Firmware' section on the ASUS Security Advisory for more information. |
| A command injection vulnerability has been identified in bwdpi. A remote, authenticated attacker could leverage this vulnerability to potentially execute arbitrary commands, leading to the device executing unintended instructions.
Refer to the 'Security Update for ASUS Router Firmware' section on the ASUS Security Advisory for more information. |
| A local privilege escalation vulnerability exists in
the restore mechanism of
ASUS System Control Interface. It can be triggered when an unprivileged actor copies files without proper validation into protected system paths, potentially leading to arbitrary files being executed as SYSTEM.
For more information, please refer to section Security Update for MyASUS in the ASUS Security Advisory. |
| Incorrect default permissions issue exists in Security Point (Windows) of MaLion prior to Ver.5.3.4. If this vulnerability is exploited, an arbitrary file could be placed in the specific folder by a user who can log in to the system where the product's Windows client is installed. If the file is a specially crafted DLL file, arbitrary code could be executed with SYSTEM privilege. |
| An issue was discovered in eTimeTrackLite Web thru 12.0 (20250704). There is a permission control flaw that allows unauthorized attackers to access specific routes and modify database connection configurations. |
| A flaw was found in the Observability Operator. The Operator creates a ServiceAccount with *ClusterRole* upon deployment of the *Namespace-Scoped* Custom Resource MonitorStack. This issue allows an adversarial Kubernetes Account with only namespaced-level roles, for example, a tenant controlling a namespace, to create a MonitorStack in the authorized namespace and then elevate permission to the cluster level by impersonating the ServiceAccount created by the Operator, resulting in privilege escalation and other issues. |
