| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc95xx: Limit packet length to skb->len
Packet length retrieved from descriptor may be larger than
the actual socket buffer length. In such case the cloned
skb passed up the network stack will leak kernel memory contents. |
| Zohocorp ManageEngine Exchange Reporter Plus through 5721 are vulnerable to ReDOS vulnerability in the search module. |
| A vulnerability was found in libX11 due to an infinite loop within the PutSubImage() function. This flaw allows a local user to consume all available system resources and cause a denial of service condition. |
| In the Linux kernel, the following vulnerability has been resolved:
rethook: fix a potential memleak in rethook_alloc()
In rethook_alloc(), the variable rh is not freed or passed out
if handler is NULL, which could lead to a memleak, fix it.
[Masami: Add "rethook:" tag to the title.]
Acke-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> |
| In the Linux kernel, the following vulnerability has been resolved:
iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()
If iio_trigger_register() returns error, it should call iio_trigger_free()
to give up the reference that hold in iio_trigger_alloc(), so that it can
call iio_trig_release() to free memory when the refcount hit to 0. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()
dev_set_name() allocates memory for name, it need be freed
when device_add() fails, call put_device() to give up the
reference that hold in device_initialize(), so that it can
be freed in kobject_cleanup() when the refcount hit to 0.
Fault injection test can trigger this:
unreferenced object 0xffff8e8340a7b4c0 (size 32):
comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s)
hex dump (first 32 bytes):
69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge
72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............
backtrace:
[<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360
[<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0
[<000000003636c520>] kstrdup+0x2d/0x60
[<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90
[<0000000092efe493>] dev_set_name+0x4e/0x70 |
| MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a memory leak
We forgot to free new_model_number |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: fix firmware memory leaks
Free the memory used to hold the results of firmware image processing
when the module is unloaded.
Fix the related issue of the same memory being leaked if processing
of the firmware image fails during module load.
Ensure all firmware GEM objects are destroyed if firmware image
processing fails.
Fixes memory leaks on powervr module unload detected by Kmemleak:
unreferenced object 0xffff000042e20000 (size 94208):
comm "modprobe", pid 470, jiffies 4295277154
hex dump (first 32 bytes):
02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE.
d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H.
backtrace (crc dd329dec):
kmemleak_alloc+0x30/0x40
___kmalloc_large_node+0x140/0x188
__kmalloc_large_node_noprof+0x2c/0x13c
__kmalloc_noprof+0x48/0x4c0
pvr_fw_init+0xaa4/0x1f50 [powervr]
unreferenced object 0xffff000042d20000 (size 20480):
comm "modprobe", pid 470, jiffies 4295277154
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................
00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................
backtrace (crc 395b02e3):
kmemleak_alloc+0x30/0x40
___kmalloc_large_node+0x140/0x188
__kmalloc_large_node_noprof+0x2c/0x13c
__kmalloc_noprof+0x48/0x4c0
pvr_fw_init+0xb0c/0x1f50 [powervr] |
| In the Linux kernel, the following vulnerability has been resolved:
cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path
In the for loop used to allocate the loc_array and bmap for each port, a
memory leak is possible when the allocation for loc_array succeeds,
but the allocation for bmap fails. This is because when the control flow
goes to the label free_eth_finfo, only the allocations starting from
(i-1)th iteration are freed.
Fix that by freeing the loc_array in the bmap allocation error path. |
| A high privileged remote attacker can exhaust critical system resources by sending specifically crafted POST requests to the send-sms action in fast succession. |
| A high privileged remote attacker can exhaust critical system resources by sending specifically crafted POST requests to the send-mail action in fast succession. |
| A vulnerability was found in Apereo CAS 5.2.6. It has been declared as problematic. This vulnerability affects unknown code of the file cas-5.2.6\core\cas-server-core-configuration-metadata-repository\src\main\java\org\apereo\cas\metadata\rest\CasConfigurationMetadataServerController.java. The manipulation of the argument Name leads to inefficient regular expression complexity. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in Apereo CAS 5.2.6. It has been classified as problematic. This affects the function ResponseEntity of the file cas-5.2.6\webapp-mgmt\cas-management-webapp-support\src\main\java\org\apereo\cas\mgmt\services\web\ManageRegisteredServicesMultiActionController.java. The manipulation of the argument Query leads to inefficient regular expression complexity. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Summer Pearl Group Vacation Rental Management Platform prior to 1.0.2 is susceptible to a Slowloris-style Denial-of-Service (DoS) condition in the HTTP connection handling layer, where an attacker that opens and maintains many slow or partially-completed HTTP connections can exhaust the server’s connection pool and worker capacity, preventing legitimate users and APIs from accessing the service. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix memory leak in ath12k_pci_remove()
Kmemleak reported this error:
unreferenced object 0xffff1c165cec3060 (size 32):
comm "insmod", pid 560, jiffies 4296964570 (age 235.596s)
backtrace:
[<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0
[<000000001203b155>] kmalloc_trace+0x40/0x88
[<0000000028adc9c8>] _request_firmware+0xb8/0x608
[<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80
[<000000005011a682>] local_pci_probe+0x48/0xd0
[<00000000077cd295>] pci_device_probe+0xb4/0x200
[<0000000087184c94>] really_probe+0x150/0x2c0
The firmware memory was allocated in ath12k_pci_probe(), but not
freed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is
set. So call ath12k_fw_unmap() to free the memory.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix multishot accept request leaks
Having REQ_F_POLLED set doesn't guarantee that the request is
executed as a multishot from the polling path. Fortunately for us, if
the code thinks it's multishot issue when it's not, it can only ask to
skip completion so leaking the request. Use issue_flags to mark
multipoll issues. |
| GE Multilink ML800, ML1200, ML1600, and ML2400 switches with firmware 4.2.1 and earlier and Multilink ML810, ML3000, and ML3100 switches with firmware 5.2.0 and earlier allow remote attackers to cause a denial of service (resource consumption or reboot) via crafted packets. |
| Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions < 1.14.1) on all platforms allows attackers to crash the service via network.
Root Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.
The bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the 1.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version < 1.14.0.
Affected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.
How to Fix: we provide two methods, you can choose one of them:
1. Upgrade bRPC to version 1.14.1.
2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually.
No matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag redis_max_allocation_size to set a larger limit. |
| Uncontrolled Resource Consumption vulnerability in Apache Tomcat if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.8, from 10.1.0-M1 through 10.1.42, from 9.0.0.M1 through 9.0.106.
The following versions were EOL at the time the CVE was created but are
known to be affected: 8.5.0 through 8.5.100. Other EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.9, 10.1.43 or 9.0.107, which fix the issue. |
