| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: at86rf230: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. In the Tx case we then leak
the skb structure.
Free the skb structure upon error before returning when appropriate.
As the 'is_tx = 0' cannot be moved in the complete handler because of a
possible race between the delay in switching to STATE_RX_AACK_ON and a
new interrupt, we introduce an intermediate 'was_tx' boolean just for
this purpose.
There is no Fixes tag applying here, many changes have been made on this
area and the issue kind of always existed. |
| A vulnerability classified as problematic has been found in FFmpeg up to 6e26f57f672b05e7b8b052007a83aef99dc81ccb. This affects the function audio_element_obu of the file libavformat/iamf_parse.c of the component IAMF File Handler. The manipulation of the argument num_parameters leads to memory leak. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of the patch is 0526535cd58444dd264e810b2f3348b4d96cff3b. It is recommended to apply a patch to fix this issue. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker case DOS through missing release of memory. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent, unauthenticated attacker to cause an FPC to crash, leading to Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, in an EVPN-VXLAN scenario, when specific ARP packets are received on an IPv4 network, or specific NDP packets are received on an IPv6 network, kernel heap memory leaks, which eventually leads to an FPC crash and restart.
This issue does not affect MX Series platforms.
Heap size growth on FPC can be seen using below command.
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt 1min 5min 15min DRAM (MB) Heap Buffer
0 Online 45 3 0 2 2 2 32768 19 0 <<<<<<< Heap increase in all fPCs
This issue affects Junos OS:
* All versions before 21.2R3-S7,
* 21.4 versions before 21.4R3-S4,
* 22.2 versions before 22.2R3-S1,
* 22.3 versions before 22.3R3-S1,
* 22.4 versions before 22.4R2-S2, 22.4R3.
and Junos OS Evolved:
* All versions before 21.2R3-S7-EVO,
* 21.4-EVO versions before 21.4R3-S4-EVO,
* 22.2-EVO versions before 22.2R3-S1-EVO,
* 22.3-EVO versions before 22.3R3-S1-EVO,
* 22.4-EVO versions before 22.4R3-EVO. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Tunnel Driver (jtd) of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause Denial of Service.
Receipt of specifically malformed IPv6 packets, destined to the device, causes kernel memory to not be freed, resulting in memory exhaustion leading to a system crash and Denial of Service (DoS). Continuous receipt and processing of these packets will continue to exhaust kernel memory, creating a sustained Denial of Service (DoS) condition.
This issue only affects systems configured with IPv6.
This issue affects Junos OS Evolved:
* from 22.4-EVO before 22.4R3-S5-EVO,
* from 23.2-EVO before 23.2R2-S2-EVO,
* from 23.4-EVO before 23.4R2-S2-EVO,
* from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO.
This issue does not affect Juniper Networks Junos OS Evolved versions prior to 22.4R1-EVO. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix handling of plane refcount
[Why]
The mechanism to backup and restore plane states doesn't maintain
refcount, which can cause issues if the refcount of the plane changes
in between backup and restore operations, such as memory leaks if the
refcount was supposed to go down, or double frees / invalid memory
accesses if the refcount was supposed to go up.
[How]
Cache and re-apply current refcount when restoring plane states. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential memory leak in DMUB hw_init
[Why]
On resume we perform DMUB hw_init which allocates memory:
dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc
That results in memory leak in suspend/resume scenarios.
[How]
Allocate memory for the DC wrapper to DMUB only if it was not
allocated before.
No need to reallocate it on suspend/resume. |
| Missing release of memory after effective lifetime in Windows Cryptographic Services allows an unauthorized attacker to execute code over a network. |
| A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. This issue affects the function H5FL__malloc of the file src/H5FL.c. The manipulation leads to memory leak. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. |
| A vulnerability classified as problematic has been found in HTACG tidy-html5 5.8.0. Affected is the function defaultAlloc of the file src/alloc.c. The manipulation leads to memory leak. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. |
| The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function. |
| A vulnerability, which was classified as problematic, was found in TechPowerUp GPU-Z 2.23.0. Affected is the function sub_140001880 in the library GPU-Z.sys of the component 0x8000645C IOCTL Handler. The manipulation leads to memory leak. It is possible to launch the attack on the local host. 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. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues. |
| In the Linux kernel, the following vulnerability has been resolved:
netrom: Decrease sock refcount when sock timers expire
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().
Function sk_reset_timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix io_req_prep_async with provided buffers
io_req_prep_async() can import provided buffers, commit the ring state
by giving up on that before, it'll be reimported later if needed. |
| Undici is an HTTP/1.1 client for Node.js. Prior to versions 5.29.0, 6.21.2, and 7.5.0, applications that use undici to implement a webhook-like system are vulnerable. If the attacker set up a server with an invalid certificate, and they can force the application to call the webhook repeatedly, then they can cause a memory leak. This has been patched in versions 5.29.0, 6.21.2, and 7.5.0. As a workaound, avoid calling a webhook repeatedly if the webhook fails. |
| In the Linux kernel, the following vulnerability has been resolved:
siox: fix possible memory leak in siox_device_add()
If device_register() returns error in siox_device_add(),
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(), and sdevice is freed in siox_device_release(),
set it to null in error path. |
| In the Linux kernel, the following vulnerability has been resolved:
misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
which may carry uninitialized data to the userspace, as observed by
KMSAN:
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
instrument_copy_to_user ./include/linux/instrumented.h:121
_copy_to_user+0x5f/0xb0 lib/usercopy.c:33
copy_to_user ./include/linux/uaccess.h:169
vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
vfs_ioctl fs/ioctl.c:51
...
Uninit was stored to memory at:
kmemdup+0x74/0xb0 mm/util.c:131
dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
...
Local variable ev created at:
qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
Bytes 28-31 of 48 are uninitialized
Memory access of size 48 starts at ffff888035155e00
Data copied to user address 0000000020000100
Use memset() to prevent the infoleaks.
Also speculatively fix qp_notify_peer_local(), which may suffer from the
same problem. |
| gpac v2.2.1 was discovered to contain a memory leak via the gfio_blob variable in the gf_fileio_from_blob function. |
