| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A GPU kernel can read sensitive data from another GPU kernel (even from another user or app) through an optimized GPU memory region called _local memory_ on various architectures. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
During backref walking, at resolve_indirect_refs(), if we get an error
we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
which frees all the elements in the ulist - however that does not free
any inode lists that may be attached to elements, through the 'aux' field
of a ulist node, so we end up leaking lists if we have any attached to
the unodes.
Fix this by calling free_leaf_list() instead of ulist_free() when we exit
from resolve_indirect_refs(). The static function free_leaf_list() is
moved up for this to be possible and it's slightly simplified by removing
unnecessary code. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ir_toy: fix a memleak in irtoy_tx
When irtoy_command fails, buf should be freed since it is allocated by
irtoy_tx, or there is a memleak. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq->ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has
completed, where for sure sq->ctrl reference is final, and move forward
based on that.
This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: use memset avoid memory leaks
Use memset to initialize structs to prevent memory leaks
in l2cap_ecred_connect |
|
A Missing Release of Memory after Effective Lifetime vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause an rpd crash, leading to Denial of Service (DoS).
On all Junos OS and Junos OS Evolved platforms, when traffic engineering is enabled for OSPF or ISIS, and a link flaps, a patroot memory leak is observed. This memory leak, over time, will lead to an rpd crash and restart.
The memory usage can be monitored using the below command.
user@host> show task memory detail | match patroot
This issue affects:
Juniper Networks Junos OS
* All versions earlier than 21.2R3-S3;
* 21.3 versions earlier than 21.3R3-S5;
* 21.4 versions earlier than 21.4R3-S3;
* 22.1 versions earlier than 22.1R3;
* 22.2 versions earlier than 22.2R3.
Juniper Networks Junos OS Evolved
* All versions earlier than 21.3R3-S5-EVO;
* 21.4 versions earlier than 21.4R3-EVO;
* 22.1 versions earlier than 22.1R3-EVO;
* 22.2 versions earlier than 22.2R3-EVO.
|
|
A Missing Release of Memory after Effective Lifetime vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network-based attacker to cause a Denial of Service (DoS).
In a Juniper Flow Monitoring (jflow) scenario route churn that causes BGP next hops to be updated will cause a slow memory leak and eventually a crash and restart of rpd.
Thread level memory utilization for the areas where the leak occurs can be checked using the below command:
user@host> show task memory detail | match so_in
so_in6 28 32 344450 11022400 344760 11032320
so_in 8 16 1841629 29466064 1841734 29467744
This issue affects:
Junos OS
* 21.4 versions earlier than 21.4R3;
* 22.1 versions earlier than 22.1R3;
* 22.2 versions earlier than 22.2R3.
Junos OS Evolved
* 21.4-EVO versions earlier than 21.4R3-EVO;
* 22.1-EVO versions earlier than 22.1R3-EVO;
* 22.2-EVO versions earlier than 22.2R3-EVO.
This issue does not affect:
Juniper Networks Junos OS versions earlier than 21.4R1.
Juniper Networks Junos OS Evolved versions earlier than 21.4R1.
|
| imlib2 v1.9.1 was discovered to mishandle memory allocation in the function init_imlib_fonts(). |
|
A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on MX Series allows an adjacent, unauthenticated attacker to cause a Denial of Service (DoS).
If an MX Series device receives PTP packets on an MPC3E that doesn't support PTP this causes a memory leak which will result in unpredictable behavior and ultimately in an MPC crash and restart.
To monitor for this issue, please use the following FPC vty level commands:
show heap
shows an increase in "LAN buffer" utilization and
show clksync ptp nbr-upd-info
shows non-zero "Pending PFEs" counter.
This issue affects Juniper Networks Junos OS on MX Series with MPC3E:
* All versions earlier than 20.4R3-S3;
* 21.1 versions earlier than 21.1R3-S4;
* 21.2 versions earlier than 21.2R3;
* 21.3 versions earlier than 21.3R2-S1, 21.3R3;
* 21.4 versions earlier than 21.4R2;
* 22.1 versions earlier than 22.1R2.
|
| An issue was discovered in button_open in login/logind-button.c in systemd before 243. When executing the udevadm trigger command, a memory leak may occur. |
| freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function. |
| A particular case of memory sharing is mishandled in the virtual memory system. This is very similar to SA-21:08.vm, but with a different root cause.
An unprivileged local user process can maintain a mapping of a page after it is freed, allowing that process to read private data belonging to other processes or the kernel. |
| openvswitch 2.17.8 was discovered to contain a memory leak via the function xmalloc__ in openvswitch-2.17.8/lib/util.c. |
| By spoofing the target resolver with responses that have a malformed EdDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources. |
| By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources. |
| An attacker can leverage this flaw to gradually erode available memory to the point where named crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service. |
| In Node.js, the `ReadFileUtf8` internal binding leaks memory due to a corrupted pointer in `uv_fs_s.file`: a UTF-16 path buffer is allocated but subsequently overwritten when the file descriptor is set. This results in an unrecoverable memory leak on every call. Repeated use can cause unbounded memory growth, leading to a denial of service.
Impact:
* This vulnerability affects APIs relying on `ReadFileUtf8` on Node.js release lines: v20 and v22. |
| Multer is a node.js middleware for handling `multipart/form-data`. Versions prior to 2.0.0 are vulnerable to a resource exhaustion and memory leak issue due to improper stream handling. When the HTTP request stream emits an error, the internal `busboy` stream is not closed, violating Node.js stream safety guidance. This leads to unclosed streams accumulating over time, consuming memory and file descriptors. Under sustained or repeated failure conditions, this can result in denial of service, requiring manual server restarts to recover. All users of Multer handling file uploads are potentially impacted. Users should upgrade to 2.0.0 to receive a patch. No known workarounds are available. |
| SWFTools commit 772e55a2 was discovered to contain a memory leak via /lib/mem.c. |
| 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. |
