Total
821 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-52560 | 1 Redhat | 1 Enterprise Linux | 2024-08-02 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected. Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary variables"), the damon_destroy_ctx() is removed, but still call damon_new_target() and damon_new_region(), the damon_region which is allocated by kmem_cache_alloc() in damon_new_region() and the damon_target which is allocated by kmalloc in damon_new_target() are not freed. And the damon_region which is allocated in damon_new_region() in damon_set_regions() is also not freed. So use damon_destroy_target to free all the damon_regions and damon_target. unreferenced object 0xffff888107c9a940 (size 64): comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `............... backtrace: [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0 [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0 [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079cc740 (size 56): comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk backtrace: [<ffffffff819bc492>] damon_new_region+0x22/0x1c0 [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff888107c9ac40 (size 64): comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v..... backtrace: [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0 [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0 [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079ccc80 (size 56): comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk backtrace: [<ffffffff819bc492>] damon_new_region+0x22/0x1c0 [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffff ---truncated--- | ||||
| CVE-2023-52526 | 2024-08-02 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren't properly released, which could slowly cause unexpected OOMs hours later. Let's fix it now (LZ4 and DEFLATE don't have this issue.) | ||||
| CVE-2023-51258 | 1 Tortall | 1 Yasm | 2024-08-02 | 5.5 Medium |
| A memory leak issue discovered in YASM v.1.3.0 allows a local attacker to cause a denial of service via the new_Token function in the modules/preprocs/nasm/nasm-pp:1512. | ||||
| CVE-2023-48958 | 1 Gpac | 1 Gpac | 2024-08-02 | 5.5 Medium |
| gpac 2.3-DEV-rev617-g671976fcc-master contains memory leaks in gf_mpd_resolve_url media_tools/mpd.c:4589. | ||||
| CVE-2023-48090 | 1 Gpac | 1 Gpac | 2024-08-02 | 7.1 High |
| GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leaks in extract_attributes media_tools/m3u8.c:329. | ||||
| CVE-2023-48039 | 1 Gpac | 1 Gpac | 2024-08-02 | 5.5 Medium |
| GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leak in gf_mpd_parse_string media_tools/mpd.c:75. | ||||
| CVE-2023-46871 | 1 Gpac | 1 Gpac | 2024-08-02 | 5.3 Medium |
| GPAC version 2.3-DEV-rev602-ged8424300-master in MP4Box contains a memory leak in NewSFDouble scenegraph/vrml_tools.c:300. This vulnerability may lead to a denial of service. | ||||
| CVE-2023-44821 | 1 Lcdf | 1 Gifsicle | 2024-08-02 | 5.5 Medium |
| Gifsicle through 1.94, if deployed in a way that allows untrusted input to affect Gif_Realloc calls, might allow a denial of service (memory consumption). NOTE: this has been disputed by multiple parties because the Gifsicle code is not commonly used for unattended operation in which new input arrives for a long-running process, does not ship with functionality to link it into another application as a library, and does not have realistic use cases in which an adversary controls the entire command line. | ||||
| CVE-2023-41484 | 1 Cimg | 1 Cimg | 2024-08-02 | 8.1 High |
| An issue in cimg.eu Cimg Library v2.9.3 allows an attacker to obtain sensitive information via a crafted JPEG file. | ||||
| CVE-2023-41102 | 1 Opennds | 1 Opennds | 2024-08-02 | 7.5 High |
| An issue was discovered in the captive portal in OpenNDS before version 10.1.3. It has multiple memory leaks due to not freeing up allocated memory. This may lead to a Denial-of-Service condition due to the consumption of all available memory. Affected OpenNDS before version 10.1.3 fixed in OpenWrt master and OpenWrt 23.05 on 23. November by updating OpenNDS to version 10.2.0. | ||||
| CVE-2023-39978 | 2 Fedoraproject, Imagemagick | 2 Fedora, Imagemagick | 2024-08-02 | 3.3 Low |
| ImageMagick before 6.9.12-91 allows attackers to cause a denial of service (memory consumption) in Magick::Draw. | ||||
| CVE-2023-38380 | 1 Siemens | 18 6ag1543-1ax00-2xe0, 6ag1543-1ax00-2xe0 Firmware, 6gk7243-8rx30-0xe0 and 15 more | 2024-08-02 | 7.5 High |
| A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.4.29), SIMATIC CP 1243-7 LTE (All versions < V3.4.29), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.4.29), SIMATIC CP 1542SP-1 (6GK7542-6UX00-0XE0) (All versions < V2.3), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0) (All versions < V2.3), SIMATIC CP 1543-1 (6GK7543-1AX00-0XE0) (All versions < V3.0.37), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0) (All versions < V2.3), SINAMICS S210 (6SL5...) (All versions >= V6.1 < V6.1 HF2), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0) (All versions < V2.3), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0) (All versions < V2.3), SIPLUS NET CP 1543-1 (6AG1543-1AX00-2XE0) (All versions < V3.0.37). The webserver implementation of the affected products does not correctly release allocated memory after it has been used. An attacker with network access could use this vulnerability to cause a denial-of-service condition in the webserver of the affected product. | ||||
| CVE-2023-36435 | 1 Microsoft | 7 .net, Powershell, Windows 11 21h2 and 4 more | 2024-08-02 | 7.5 High |
| Microsoft QUIC Denial of Service Vulnerability | ||||
| CVE-2023-34451 | 1 Cometbft | 1 Cometbft | 2024-08-02 | 8.2 High |
| CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node. The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node. Not exposing the transaction submission RPC's would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p. | ||||
| CVE-2023-34450 | 1 Cometbft | 1 Cometbft | 2024-08-02 | 3.7 Low |
| CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to "debug" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`. Case 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node. In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node's peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded. The theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated. As the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that "for" loop to never be reached). This regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don't set the log output to "json", leave at "plain", or don't set the consensus logging module to "debug", leave it at "info" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one's nginx setup). | ||||
| CVE-2023-33718 | 1 Mp4v2 Project | 1 Mp4v2 | 2024-08-02 | 8.8 High |
| mp4v2 v2.1.3 was discovered to contain a memory leak via MP4File::ReadString() at mp4file_io.cpp | ||||
| CVE-2023-33717 | 1 Mp4v2 Project | 1 Mp4v2 | 2024-08-02 | 5.5 Medium |
| mp4v2 v2.1.3 was discovered to contain a memory leak when a method calling MP4File::ReadBytes() had allocated memory but did not catch exceptions thrown by ReadBytes() | ||||
| CVE-2023-33719 | 1 Mp4v2 | 1 Mp4v2 | 2024-08-02 | 5.5 Medium |
| mp4v2 v2.1.3 was discovered to contain a memory leak via MP4SdpAtom::Read() at atom_sdp.cpp | ||||
| CVE-2023-33716 | 1 Mp4v2 | 1 Mp4v2 | 2024-08-02 | 5.5 Medium |
| mp4v2 v2.1.3 was discovered to contain a memory leak via the class MP4StringProperty at mp4property.cpp. | ||||
| CVE-2023-33460 | 4 Debian, Fedoraproject, Redhat and 1 more | 5 Debian Linux, Fedora, Enterprise Linux and 2 more | 2024-08-02 | 6.5 Medium |
| There's a memory leak in yajl 2.1.0 with use of yajl_tree_parse function. which will cause out-of-memory in server and cause crash. | ||||