Total
730 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-26946 | 1 Linux | 1 Linux Kernel | 2025-09-18 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ] | |||||
| CVE-2024-38306 | 1 Linux | 1 Linux Kernel | 2025-09-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: protect folio::private when attaching extent buffer folios [BUG] Since v6.8 there are rare kernel crashes reported by various people, the common factor is bad page status error messages like this: BUG: Bad page state in process kswapd0 pfn:d6e840 page: refcount:0 mapcount:0 mapping:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone=2|lastcpupid=0x3fffff) page_type: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: non-NULL mapping [CAUSE] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") changes the sequence when allocating a new extent buffer. Previously we always called grab_extent_buffer() under mapping->i_private_lock, to ensure the safety on modification on folio::private (which is a pointer to extent buffer for regular sectorsize). This can lead to the following race: Thread A is trying to allocate an extent buffer at bytenr X, with 4 4K pages, meanwhile thread B is trying to release the page at X + 4K (the second page of the extent buffer at X). Thread A | Thread B -----------------------------------+------------------------------------- | btree_release_folio() | | This is for the page at X + 4K, | | Not page X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() for the | | |- atomic_dec_and_test(eb->refs) | page at bytenr X (the first | | | | page). | | | | Which returned -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Returned the first page locked. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Returned false | | | | |- folio_detach_private() | | |- folio_detach_private() for X | |- folio_test_private() | | |- folio_test_private() | Returned true | | | Returned true |- folio_put() | |- folio_put() Now there are two puts on the same folio at folio X, leading to refcount underflow of the folio X, and eventually causing the BUG_ON() on the page->mapping. The condition is not that easy to hit: - The release must be triggered for the middle page of an eb If the release is on the same first page of an eb, page lock would kick in and prevent the race. - folio_detach_private() has a very small race window It's only between folio_test_private() and folio_clear_private(). That's exactly when mapping->i_private_lock is used to prevent such race, and commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") screwed that up. At that time, I thought the page lock would kick in as filemap_release_folio() also requires the page to be locked, but forgot the filemap_release_folio() only locks one page, not all pages of an extent buffer. [FIX] Move all the code requiring i_private_lock into attach_eb_folio_to_filemap(), so that everything is done with proper lock protection. Furthermore to prevent future problems, add an extra lockdep_assert_locked() to ensure we're holding the proper lock. To reproducer that is able to hit the race (takes a few minutes with instrumented code inserting delays to alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); do echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory done } run_tar () { while(true); do for x in `seq 1 80` ; do tar cf /dev/zero /mnt > /dev/null & done wait done } mkfs.btrfs -f -d single -m single ---truncated--- | |||||
| CVE-2024-32475 | 1 Envoyproxy | 1 Envoy | 2025-09-04 | N/A | 7.5 HIGH |
| Envoy is a cloud-native, open source edge and service proxy. When an upstream TLS cluster is used with `auto_sni` enabled, a request containing a `host`/`:authority` header longer than 255 characters triggers an abnormal termination of Envoy process. Envoy does not gracefully handle an error when setting SNI for outbound TLS connection. The error can occur when Envoy attempts to use the `host`/`:authority` header value longer than 255 characters as SNI for outbound TLS connection. SNI length is limited to 255 characters per the standard. Envoy always expects this operation to succeed and abnormally aborts the process when it fails. This vulnerability is fixed in 1.30.1, 1.29.4, 1.28.3, and 1.27.5. | |||||
| CVE-2024-50614 | 1 Tinyxml2 Project | 1 Tinyxml2 | 2025-09-04 | N/A | 6.5 MEDIUM |
| TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/16, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef. | |||||
| CVE-2024-50615 | 1 Tinyxml2 Project | 1 Tinyxml2 | 2025-09-04 | N/A | 6.5 MEDIUM |
| TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/digit, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef. | |||||
| CVE-2025-9405 | 1 Open5gs | 1 Open5gs | 2025-09-02 | 5.0 MEDIUM | 5.3 MEDIUM |
| A security flaw has been discovered in Open5GS up to 2.7.5. The impacted element is the function gmm_state_exception of the file src/amf/gmm-sm.c. The manipulation results in reachable assertion. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited. The patch is identified as 8e5fed16114f2f5e40bee1b161914b592b2b7b8f. Applying a patch is advised to resolve this issue. | |||||
| CVE-2025-24798 | 1 Meshtastic | 1 Meshtastic Firmware | 2025-08-22 | N/A | 4.3 MEDIUM |
| Meshtastic is an open source mesh networking solution. From 1.2.1 until 2.6.2, a packet sent to the routing module that contains want_response==true causes a crash. This can lead to a degradation of service for nodes within range of a malicious sender, or via MQTT if downlink is enabled. This vulnerability is fixed in 2.6.2. | |||||
| CVE-2025-30034 | 1 Siemens | 1 Simatic Rtls Locating Manager | 2025-08-20 | N/A | 6.2 MEDIUM |
| A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V3.3). Affected devices do not properly validate input sent to its listening port on the local loopback interface. This could allow an unauthenticated local attacker to cause a denial of service condition. | |||||
| CVE-2025-27073 | 1 Qualcomm | 340 Ar8035, Ar8035 Firmware, Csr8811 and 337 more | 2025-08-20 | N/A | 7.5 HIGH |
| Transient DOS while creating NDP instance. | |||||
| CVE-2025-21452 | 1 Qualcomm | 160 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 157 more | 2025-08-20 | N/A | 7.5 HIGH |
| Transient DOS while processing a random-access response (RAR) with an invalid PDU length on LTE network. | |||||
| CVE-2025-8804 | 1 Open5gs | 1 Open5gs | 2025-08-15 | 5.0 MEDIUM | 5.3 MEDIUM |
| A vulnerability was found in Open5GS up to 2.7.5. Affected by this vulnerability is the function ngap_build_downlink_nas_transport of the component AMF. The manipulation leads to reachable assertion. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.7.6 is able to address this issue. The identifier of the patch is bca0a7b6e01d254f4223b83831162566d4626428. It is recommended to upgrade the affected component. | |||||
| CVE-2023-33043 | 1 Qualcomm | 118 Ar8035, Ar8035 Firmware, Qca6391 and 115 more | 2025-08-11 | N/A | 7.5 HIGH |
| Transient DOS in Modem when a Beam switch request is made with a non-configured BWP. | |||||
| CVE-2023-33044 | 1 Qualcomm | 180 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 177 more | 2025-08-11 | N/A | 7.5 HIGH |
| Transient DOS in Data modem while handling TLB control messages from the Network. | |||||
| CVE-2023-33096 | 1 Qualcomm | 204 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 201 more | 2025-08-11 | N/A | 7.5 HIGH |
| Transient DOS while processing DL NAS Transport message, as specified in 3GPP 24.501 v16. | |||||
| CVE-2023-24843 | 1 Qualcomm | 132 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 129 more | 2025-08-11 | N/A | 7.5 HIGH |
| Transient DOS in Modem while triggering a camping on an 5G cell. | |||||
| CVE-2023-43529 | 1 Qualcomm | 322 315 5g Iot Modem, 315 5g Iot Modem Firmware, Aqt1000 and 319 more | 2025-08-11 | N/A | 7.5 HIGH |
| Transient DOS while processing IKEv2 Informational request messages, when a malformed fragment packet is received. | |||||
| CVE-2024-10455 | 1 D3tn | 1 Ud3tn | 2025-08-07 | N/A | 7.5 HIGH |
| Reachable Assertion in BPv7 parser in µD3TN v0.14.0 allows attacker to disrupt service via malformed Extension Block | |||||
| CVE-2024-42645 | 1 Flashmq | 1 Flashmq | 2025-08-06 | N/A | 7.5 HIGH |
| An issue in FlashMQ v1.14.0 allows attackers to cause an assertion failure via sending a crafted retain message, leading to a Denial of Service (DoS). | |||||
| CVE-2024-42644 | 1 Flashmq | 1 Flashmq | 2025-08-06 | N/A | 7.5 HIGH |
| FlashMQ v1.14.0 was discovered to contain an assertion failure in the function PublishCopyFactory::getNewPublish, which occurs when the QoS value of the publish object is greater than 0. | |||||
| CVE-2021-1440 | 1 Cisco | 1 Ios Xr | 2025-08-01 | N/A | 6.8 MEDIUM |
| A vulnerability in the implementation of the Resource Public Key Infrastructure (RPKI) feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to cause the Border Gateway Protocol (BGP) process to crash, resulting in a denial of service (DoS) condition. This vulnerability is due to the incorrect handling of a specific RPKI to Router (RTR) Protocol packet header. An attacker could exploit this vulnerability by compromising the RPKI validator server and sending a specifically crafted RTR packet to an affected device. Alternatively, the attacker could use man-in-the-middle techniques to impersonate the RPKI validator server and send a specifically crafted RTR response packet over the established RTR TCP connection to the affected device. A successful exploit could allow the attacker to cause a DoS condition because the BGP process could constantly restart and BGP routing could become unstable.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.This advisory is part of the September 2021 release of the Cisco IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see . | |||||