| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()
If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated
by dev_set_name() need be freed. As comment of device_register() says, it
should use put_device() to give up the reference in the error path. So fix
this by calling put_device(), then the name can be freed in kobject_cleanup().
The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need
goto error label in this case. |
| A vulnerability in the Eclipse Vert.x toolkit results in a memory leak due to using Netty FastThreadLocal data structures. Specifically, when the Vert.x HTTP client establishes connections to different hosts, triggering the memory leak. The leak can be accelerated with intimate runtime knowledge, allowing an attacker to exploit this vulnerability. For instance, a server accepting arbitrary internet addresses could serve as an attack vector by connecting to these addresses, thereby accelerating the memory leak. |
| A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support. When processing an unknown SNI server name assigned the default certificate instead of a mapped certificate, the SSL context is erroneously cached in the server name map, leading to memory exhaustion. This flaw allows attackers to send TLS client hello messages with fake server names, triggering a JVM out-of-memory error. |
| 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. |
| 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 |
| 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:
x86/mce: use is_copy_from_user() to determine copy-from-user context
Patch series "mm/hwpoison: Fix regressions in memory failure handling",
v4.
## 1. What am I trying to do:
This patchset resolves two critical regressions related to memory failure
handling that have appeared in the upstream kernel since version 5.17, as
compared to 5.10 LTS.
- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space
## 2. What is the expected outcome and why
- For copyin case:
Kernel can recover from poison found where kernel is doing get_user() or
copy_from_user() if those places get an error return and the kernel return
-EFAULT to the process instead of crashing. More specifily, MCE handler
checks the fixup handler type to decide whether an in kernel #MC can be
recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code
specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.
- For instr case:
If a poison found while instruction fetching in user space, full recovery
is possible. User process takes #PF, Linux allocates a new page and fills
by reading from storage.
## 3. What actually happens and why
- For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new
extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the
extable fixup type for copy-from-user operations, changing it from
EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS
handling when posion found in get_user() or copy_from_user().
- For instr case: user process is killed by a SIGBUS signal due to #CMCI
and #MCE race
When an uncorrected memory error is consumed there is a race between the
CMCI from the memory controller reporting an uncorrected error with a UCNA
signature, and the core reporting and SRAR signature machine check when
the data is about to be consumed.
### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]
Prior to Icelake memory controllers reported patrol scrub events that
detected a previously unseen uncorrected error in memory by signaling a
broadcast machine check with an SRAO (Software Recoverable Action
Optional) signature in the machine check bank. This was overkill because
it's not an urgent problem that no core is on the verge of consuming that
bad data. It's also found that multi SRAO UCE may cause nested MCE
interrupts and finally become an IERR.
Hence, Intel downgrades the machine check bank signature of patrol scrub
from SRAO to UCNA (Uncorrected, No Action required), and signal changed to
#CMCI. Just to add to the confusion, Linux does take an action (in
uc_decode_notifier()) to try to offline the page despite the UC*NA*
signature name.
### Background: why #CMCI and #MCE race when poison is consuming in
Intel platform [1]
Having decided that CMCI/UCNA is the best action for patrol scrub errors,
the memory controller uses it for reads too. But the memory controller is
executing asynchronously from the core, and can't tell the difference
between a "real" read and a speculative read. So it will do CMCI/UCNA if
an error is found in any read.
Thus:
1) Core is clever and thinks address A is needed soon, issues a
speculative read.
2) Core finds it is going to use address A soon after sending the read
request
3) The CMCI from the memory controller is in a race with MCE from the
core that will soon try to retire the load from address A.
Quite often (because speculation has got better) the CMCI from the memory
controller is delivered before the core is committed to the instruction
reading address A, so the interrupt is taken, and Linux offlines the page
(marking it as poison).
## Why user process is killed for instr case
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported
"not
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp
structure has to be removed explicitly to avoid a resource leak.
Free the structure in case the allocation of the firmware structure fails
during the firmware initialization. |
| 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. |
| 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:
wifi: ath12k: Avoid memory leak while enabling statistics
Driver uses monitor destination rings for extended statistics mode and
standalone monitor mode. In extended statistics mode, TLVs are parsed from
the buffer received from the monitor destination ring and assigned to the
ppdu_info structure to update per-packet statistics. In standalone monitor
mode, along with per-packet statistics, the packet data (payload) is
captured, and the driver updates per MSDU to mac80211.
When the AP interface is enabled, only extended statistics mode is
activated. As part of enabling monitor rings for collecting statistics,
the driver subscribes to HAL_RX_MPDU_START TLV in the filter
configuration. This TLV is received from the monitor destination ring, and
kzalloc for the mon_mpdu object occurs, which is not freed, leading to a
memory leak. The kzalloc for the mon_mpdu object is only required while
enabling the standalone monitor interface. This causes a memory leak while
enabling extended statistics mode in the driver.
Fix this memory leak by removing the kzalloc for the mon_mpdu object in
the HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone
monitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs.
These TLV tags will be handled properly when enabling standalone monitor
mode in the future.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 |
| 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. |
| Late Release of Memory after Effective Lifetime vulnerability in Apache HTTP Server.
This issue affects Apache HTTP Server: from 2.4.17 up to 2.4.63.
Users are recommended to upgrade to version 2.4.64, which fixes the issue. |
| libLAS 1.8.1 contains a memory leak vulnerability in /libLAS/apps/ts2las.cpp. |
| freeglut through 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddMenuEntry function. |
| freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function. |
| 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. |
