Filtered by CWE-617
Total 681 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2023-43523 1 Qualcomm 284 Ar8035, Ar8035 Firmware, Csr8811 and 281 more 2025-06-17 7.5 High
Transient DOS while processing 11AZ RTT management action frame received through OTA.
CVE-2024-3652 2 Libreswan, Redhat 7 Libreswan, Enterprise Linux, Openshift and 4 more 2025-06-17 6.5 Medium
The Libreswan Project was notified of an issue causing libreswan to restart when using IKEv1 without specifying an esp= line. When the peer requests AES-GMAC, libreswan's default proposal handler causes an assertion failure and crashes and restarts. IKEv2 connections are not affected.
CVE-2025-5501 1 Open5gs 1 Open5gs 2025-06-13 5.3 Medium
A vulnerability classified as problematic was found in Open5GS up to 2.7.3. Affected by this vulnerability is the function ngap_handle_path_switch_request_transfer of the file src/smf/ngap-handler.c of the component NGAP PathSwitchRequest Message Handler. The manipulation leads to reachable assertion. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The patch is named 2daa44adab762c47a8cef69cc984946973a845b3. It is recommended to apply a patch to fix this issue.
CVE-2021-3326 6 Debian, Fujitsu, Gnu and 3 more 18 Debian Linux, M10-1, M10-1 Firmware and 15 more 2025-06-09 7.5 High
The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.
CVE-2020-29562 3 Fedoraproject, Gnu, Netapp 3 Fedora, Glibc, E-series Santricity Os Controller 2025-06-09 4.8 Medium
The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.
CVE-2023-34969 4 Debian, Fedoraproject, Freedesktop and 1 more 5 Debian Linux, Fedora, Dbus and 2 more 2025-06-09 6.5 Medium
D-Bus before 1.15.6 sometimes allows unprivileged users to crash dbus-daemon. If a privileged user with control over the dbus-daemon is using the org.freedesktop.DBus.Monitoring interface to monitor message bus traffic, then an unprivileged user with the ability to connect to the same dbus-daemon can cause a dbus-daemon crash under some circumstances via an unreplyable message. When done on the well-known system bus, this is a denial-of-service vulnerability. The fixed versions are 1.12.28, 1.14.8, and 1.15.6.
CVE-2025-5520 1 Open5gs 1 Open5gs 2025-06-09 5.3 Medium
A vulnerability was found in Open5GS up to 2.7.3. It has been classified as problematic. Affected is the function gmm_state_authentication/emm_state_authentication of the component AMF/MME. The manipulation leads to reachable assertion. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The name of the patch is 9f5d133657850e6167231527514ee1364d37a884. It is recommended to apply a patch to fix this issue. This is a different issue than CVE-2025-1893.
CVE-2024-46751 1 Linux 1 Linux Kernel 2025-06-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.
CVE-2025-5455 1 Redhat 1 Enterprise Linux 2025-06-02 5.3 Medium
An issue was found in the private API function qDecodeDataUrl() in QtCore, which is used in QTextDocument and QNetworkReply, and, potentially, in user code. If the function was called with malformed data, for example, an URL that contained a "charset" parameter that lacked a value (such as "data:charset,"), and Qt was built with assertions enabled, then it would hit an assertion, resulting in a denial of service (abort). This impacts Qt up to 5.15.18, 6.0.0->6.5.8, 6.6.0->6.8.3 and 6.9.0. This has been fixed in 5.15.19, 6.5.9, 6.8.4 and 6.9.1.
CVE-2023-32843 1 Mediatek 36 Mt2735, Mt2737, Mt6297 and 33 more 2025-05-29 7.5 High
In 5G Modem, there is a possible system crash due to improper error handling. This could lead to remote denial of service when receiving malformed RRC messages, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01130204; Issue ID: MOLY01130204 (MSV-849).
CVE-2024-7139 2025-05-28 6.5 Medium
Due to an unchecked buffer length, a specially crafted L2CAP packet can cause a buffer overflow. This buffer overflow triggers an assert, which results in a temporary denial of service.  If a watchdog timer is not enabled, a hard reset is required to recover the device.
CVE-2024-7138 2025-05-28 6.5 Medium
An assert may be triggered, causing a temporary denial of service when a peer device sends a specially crafted malformed L2CAP packet. If a watchdog timer is not enabled, a hard reset is required to recover the device.
CVE-2021-47305 1 Linux 1 Linux Kernel 2025-05-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sync_file: Don't leak fences on merge failure Each add_fence() call does a dma_fence_get() on the relevant fence. In the error path, we weren't calling dma_fence_put() so all those fences got leaked. Also, in the krealloc_array failure case, we weren't freeing the fences array. Instead, ensure that i and fences are always zero-initialized and dma_fence_put() all the fences and kfree(fences) on every error path.
CVE-2021-47315 1 Linux 1 Linux Kernel 2025-05-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: memory: fsl_ifc: fix leak of IO mapping on probe failure On probe error the driver should unmap the IO memory. Smatch reports: drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.
CVE-2021-47322 1 Linux 1 Linux Kernel 2025-05-12 7.8 High
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix an Oops in pnfs_mark_request_commit() when doing O_DIRECT Fix an Oopsable condition in pnfs_mark_request_commit() when we're putting a set of writes on the commit list to reschedule them after a failed pNFS attempt.
CVE-2021-47351 1 Linux 1 Linux Kernel 2025-05-12 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix races between xattr_{set|get} and listxattr operations UBIFS may occur some problems with concurrent xattr_{set|get} and listxattr operations, such as assertion failure, memory corruption, stale xattr value[1]. Fix it by importing a new rw-lock in @ubifs_inode to serilize write operations on xattr, concurrent read operations are still effective, just like ext4. [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com
CVE-2025-20666 1 Mediatek 31 Mt2735, Mt6833, Mt6833p and 28 more 2025-05-12 7.5 High
In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY00650610; Issue ID: MSV-2933.
CVE-2022-23569 1 Google 1 Tensorflow 2025-05-05 6.5 Medium
Tensorflow is an Open Source Machine Learning Framework. Multiple operations in TensorFlow can be used to trigger a denial of service via `CHECK`-fails (i.e., assertion failures). This is similar to TFSA-2021-198 and has similar fixes. We have patched the reported issues in multiple GitHub commits. It is possible that other similar instances exist in TensorFlow, we will issue fixes as these are discovered. The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range.
CVE-2024-26727 2 Debian, Linux 2 Debian Linux, Linux Kernel 2025-05-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one.
CVE-2024-49954 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2025-05-04 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().