| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause incorrect control flow behavior. A successful exploit of this vulnerability might lead to data tampering. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash
Currently, we encounter the following kernel call trace when a firmware
crash occurs. This happens because the host sends WMI commands to the
firmware while it is in recovery, causing the commands to fail and
resulting in the kernel call trace.
Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the
host driver receives the firmware crash notification from MHI. This
prevents sending WMI commands to the firmware during recovery.
Call Trace:
<TASK>
dump_stack_lvl+0x75/0xc0
register_lock_class+0x6be/0x7a0
? __lock_acquire+0x644/0x19a0
__lock_acquire+0x95/0x19a0
lock_acquire+0x265/0x310
? ath12k_ce_send+0xa2/0x210 [ath12k]
? find_held_lock+0x34/0xa0
? ath12k_ce_send+0x56/0x210 [ath12k]
_raw_spin_lock_bh+0x33/0x70
? ath12k_ce_send+0xa2/0x210 [ath12k]
ath12k_ce_send+0xa2/0x210 [ath12k]
ath12k_htc_send+0x178/0x390 [ath12k]
ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k]
ath12k_wmi_cmd_send+0x62/0x190 [ath12k]
ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1
ath12k_mac_op_get_survey+0x2be/0x310 [ath12k]
ieee80211_dump_survey+0x99/0x240 [mac80211]
nl80211_dump_survey+0xe7/0x470 [cfg80211]
? kmalloc_reserve+0x59/0xf0
genl_dumpit+0x24/0x70
netlink_dump+0x177/0x360
__netlink_dump_start+0x206/0x280
genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0
? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0
? genl_op_lock.part.12+0x10/0x10
? genl_dumpit+0x70/0x70
genl_rcv_msg+0x1d0/0x290
? nl80211_del_station+0x330/0x330 [cfg80211]
? genl_get_cmd_both+0x50/0x50
netlink_rcv_skb+0x4f/0x100
genl_rcv+0x1f/0x30
netlink_unicast+0x1b6/0x260
netlink_sendmsg+0x31a/0x450
__sock_sendmsg+0xa8/0xb0
____sys_sendmsg+0x1e4/0x260
___sys_sendmsg+0x89/0xe0
? local_clock_noinstr+0xb/0xc0
? rcu_is_watching+0xd/0x40
? kfree+0x1de/0x370
? __sys_sendmsg+0x7a/0xc0
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| A logic issue was addressed with improved state management. This issue is fixed in tvOS 26, watchOS 26, macOS Sonoma 14.8, iOS 26 and iPadOS 26, macOS Sequoia 15.7, visionOS 26, iOS 18.7 and iPadOS 18.7. A UDP server socket bound to a local interface may become bound to all interfaces. |
| In the Linux kernel, the following vulnerability has been resolved:
signal: restore the override_rlimit logic
Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals. However now it's enforced unconditionally, even if
override_rlimit is set. This behavior change caused production issues.
For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo.
This prevents the process from correctly identifying the fault address and
handling the error. From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'. This can lead to unpredictable behavior and
crashes, as we observed with java applications.
Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set. This effectively
restores the old behavior. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: call the security_mmap_file() LSM hook in remap_file_pages()
The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.
So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.
The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].
The PoC:
$ cat > test.c
int main(void) {
size_t pagesz = sysconf(_SC_PAGE_SIZE);
int mfd = syscall(SYS_memfd_create, "test", 0);
const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
MAP_SHARED, mfd, 0);
unsigned int old = syscall(SYS_personality, 0xffffffff);
syscall(SYS_personality, READ_IMPLIES_EXEC | old);
syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
syscall(SYS_personality, old);
// show the RWX page exists even if W^X policy is enforced
int fd = open("/proc/self/maps", O_RDONLY);
unsigned char buf2[1024];
while (1) {
int ret = read(fd, buf2, 1024);
if (ret <= 0) break;
write(1, buf2, ret);
}
close(fd);
}
$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)
[PM: subject line tweaks] |
| A vulnerability in IPv6 traffic processing of Cisco IOS XE Wireless Controller Software for Cisco Catalyst 9000 Family Wireless Controllers could allow an unauthenticated, adjacent attacker to cause a Layer 2 (L2) loop in a configured VLAN, resulting in a denial of service (DoS) condition for that VLAN. The vulnerability is due to a logic error when processing specific link-local IPv6 traffic. An attacker could exploit this vulnerability by sending a crafted IPv6 packet that would flow inbound through the wired interface of an affected device. A successful exploit could allow the attacker to cause traffic drops in the affected VLAN, thus triggering the DoS condition. |
| HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a control flow vulnerability. The application does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways. |
| there is a possible way to bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used. |
| Missing validation of terminating delegation causes the client to continue searching the defined delegation list, even after searching a terminating delegation. This could cause the client to fetch a target from an incorrect source, altering the target contents. Users should upgrade to tough version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes. |
| SSH Tectia Server before 6.6.6 sometimes allows attackers to read and alter a user's session traffic. |
| In the Linux kernel, the following vulnerability has been resolved:
pmdomain: imx93-blk-ctrl: correct remove path
The check condition should be 'i < bc->onecell_data.num_domains', not
'bc->onecell_data.num_domains' which will make the look never finish
and cause kernel panic.
Also disable runtime to address
"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!" |
| Wasmtime is an open source runtime for WebAssembly. Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later. WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations. The specific crash happens when an exported function in a WebAssembly module (or component) performs a `return_call` (or `return_call_indirect` or `return_call_ref`) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it's possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust `panic!()`. When Wasmtime is compiled with Rust versions 1.80 and prior this means that an `extern "C"` function in Rust is raising a `panic!()`. This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort. Overall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more. This issue was discovered by routine fuzzing performed by the Wasmtime project via Google's OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild. All versions of Wasmtime which have tail calls enabled by default have been patched: * 21.0.x - patched in 21.0.2 * 22.0.x - patched in 22.0.1 * 23.0.x - patched in 23.0.3 * 24.0.x - patched in 24.0.1 * 25.0.x - patched in 25.0.2. Wasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime. The main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with `Config::wasm_tail_call(false)`. Users are otherwise encouraged to upgrade to patched versions. |
| In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write. In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
<TASK>
usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
__usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
__dev_open+0x297/0x4d0 net/core/dev.c:1417
__dev_change_flags+0x587/0x750 net/core/dev.c:8530
dev_change_flags+0x97/0x170 net/core/dev.c:8602
devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
sock_do_ioctl+0xcc/0x230 net/socket.c:1169
sock_ioctl+0x1f8/0x680 net/socket.c:1286
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
remove the USB_DIR_IN flag. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
The BOS descriptor defines a root descriptor and is the base descriptor for
accessing a family of related descriptors.
Function 'usb_get_bos_descriptor()' encounters an iteration issue when
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
the same descriptor being read repeatedly.
To address this issue, a 'goto' statement is introduced to ensure that the
pointer and the amount read is updated correctly. This ensures that the
function iterates to the next descriptor instead of reading the same
descriptor repeatedly. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: fix list iterator in fastrpc_req_mem_unmap_impl
This is another instance of incorrect use of list iterator and
checking it for NULL.
The list iterator value 'map' will *always* be set and non-NULL
by list_for_each_entry(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty (in this case, the
check 'if (!map) {' will always be false and never exit as expected).
To fix the bug, use a new variable 'iter' as the list iterator,
while use the original variable 'map' as a dedicated pointer to
point to the found element.
Without this patch, Kernel crashes with below trace:
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 0000ffff7fb03750
...
Call trace:
fastrpc_map_create+0x70/0x290 [fastrpc]
fastrpc_req_mem_map+0xf0/0x2dc [fastrpc]
fastrpc_device_ioctl+0x138/0xc60 [fastrpc]
__arm64_sys_ioctl+0xa8/0xec
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0xd4/0xfc
do_el0_svc+0x28/0x90
el0_svc+0x3c/0x130
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x18c/0x190
Code: 14000016 f94000a5 eb05029f 54000260 (b94018a6)
---[ end trace 0000000000000000 ]--- |
| An issue in phiola/src/afilter/conv.c:115 of phiola v2.0-rc22 allows a remote attacker to cause a denial of service via a crafted .wav file. |
| Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions envoy does not properly handle http 1.1 non-101 1xx responses. This can lead to downstream failures in networked devices. This issue has been addressed in versions 1.31.5 and 1.32.3. Users are advised to upgrade. There are no known workarounds for this issue. |
| Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions `sendOverloadError` is going to assume the active request exists when `envoy.load_shed_points.http1_server_abort_dispatch` is configured. If `active_request` is nullptr, only onMessageBeginImpl() is called. However, the `onMessageBeginImpl` will directly return ok status if the stream is already reset leading to the nullptr reference. The downstream reset can actually happen during the H/2 upstream reset. As a result envoy may crash. This issue has been addressed in releases 1.32.3, 1.31.5, 1.30.9, and 1.29.12. Users are advised to upgrade. Users unable to upgrade may disable `http1_server_abort_dispatch` load shed point and/or use a high threshold. |
| Envoy is a cloud-native high-performance edge/middle/service proxy. When additional address are not ip addresses, then the Happy Eyeballs sorting algorithm will crash in data plane. This issue has been addressed in releases 1.32.2, 1.31.4, and 1.30.8. Users are advised to upgrade. Users unable to upgrade may disable Happy Eyeballs and/or change the IP configuration. |
