| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
namespace: check a recursive bind mount for mount namespace loops
do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller's or older because a mount namespace that holds
a mount of its own file, or of an ancestor's, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.
That's fine for a source in the caller's own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn't fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:
151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw
Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:
after control: Shmem: 380 kB
child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok
after cycle: Shmem: 65916 kB
do_move_mount() runs check_for_nsfs_mounts() over a detached tree for
exactly that reason. Do the same for the copy before it is grafted. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close()
acp6x_pdm_dma_close() does not free the runtime->private_data buffer
allocated in acp6x_pdm_dma_open(). Add the missing kfree. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ACP MFD device leak on init failure
acp_hw_init() registers ACP child devices with mfd_add_devices() before
attaching them to the ACP power domain and initializing the hardware.
If attaching a child to the power domain fails, or if the ACP reset or
clock enable operation times out, the failure path frees only the
source cell, resource, and platform-data allocations. The child
platform devices already registered by mfd_add_devices() remain
registered and are never released.
Remove the children from the power domain and unregister the MFD
devices on failures that occur after mfd_add_devices() succeeds. Keep
mfd_add_devices() failures on the existing cleanup path since the MFD
core already rolls back partially registered children itself.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
(cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix IP instance memory leak on kobject add failure
amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with
kzalloc_flex() and initializes its embedded kobject before calling
kobject_add().
If kobject_add() fails, the return value is ignored and execution
continues without dropping the initial kobject reference. The failed
kobject is not retained in the kset list, so the normal sysfs teardown
path cannot find it. As a result, ip_hw_instance_release() is never
called and the ip_hw_instance allocation is leaked.
Call kobject_put() when kobject_add() fails so the initial reference is
dropped and ip_hw_instance_release() can free the allocation. Keep the
existing best-effort sysfs behavior by continuing with the remaining IP
entries after the failed registration.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
(cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx6: fix firmware leak on teardown
The firmware requested in gfx_v6_0_init_microcode() is not released
when the GFX block is torn down, leaking the firmware resources.
Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini()
to release the PFP, ME, CE and RLC firmware.
(cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: disable rx napi when removing device
Unloading the mt7915e module with a MT7916 triggers multiples WARN in
__netif_napi_del_locked() and in page_pool_disable_direct_recycling()
because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module
and reinsert it with a different enable_6ghz parameter to change the
frequency. The system generally becomes unstable after reinserting the
module.
Fix it by disabling rx napi inside mt7915e itself, even through napi rx is
enabled in the mt76 generic code. Disabling it in the mt76 generic code
was previously attempted and reverted because napi was disabled too
late and rx handlers could access freed structures. Note that the tx
side is enabled and disabled by the mt76 generic code.
It is disabled in mt7915_stop_hardware() since, unlike
mt7915_unregister_device(), is it also called in the probe path if an
error happens after rx napi is enabled. |
| IBM MQ 9.4.5.0 through 9.4.5.1 could allow an authenticated user to cause a denial of service by sending a specially crafted message that crashes consuming applications. |
| Pillow is a Python imaging library. From 5.1.0 until 13.0.0, Pillow's PdfParser.get_value() can recurse without a limit while reading nested PDF objects. The parser follows attacker-controlled arrays and dictionaries when an existing PDF is opened for append. An attacker can provide a deeply nested PDF to an application that saves an image with PDF append enabled. This can raise an uncaught RecursionError or terminate the worker, causing denial of service. This issue is fixed in version 13.0.0. |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()
mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template
into a stack-local struct mlxsw_sp_acl_rule_info purely to compute
rulei.values.elusage. Parsing can acquire port range registers via
mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes
through mlxsw_sp_acl_rulei_destroy(), those registers were never
released, including through chain template deletion.
Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually
release the necessary resources and call from
mlxsw_sp_flower_tmplt_create() to plug the leak.
The issue was found during a review of Wentao Liang's patch referenced
below. |
| Allocation of resources without limits or throttling in Windows SMB Server allows an unauthorized attacker to deny service over a network. |
| pupnp is an SDK for development of UPnP device and control point applications. Prior to 2.0.2, Transfer-Encoding: chunked causes the HTTP parser in upnp/src/genlib/net/http/httpparser.c to leave parser->content_length at zero while parser_parse_chunky_entity and parser_parse_chunky_body accumulate decoded bytes in parser->msg.entity. The g_maxContentLength checks in http_RecvMessage in upnp/src/genlib/net/http/httpreadwrite.c therefore reject oversized numeric Content-Length bodies but do not enforce the same limit on decoded chunked bodies. A remote peer that can reach a SOAP, GENA, miniserver, or control-point HTTP response path can make the process buffer an entity larger than the configured maximum, causing resource exhaustion and denial of service. This issue is fixed in 2.0.2. |
| Ghidra before 12.2 contains a resource allocation without limits vulnerability in FileSystemIndexHelper used by TarFileSystem and ZipFileSystem, which store unbounded archive entries. Attackers can persuade a user to open or batch-import a crafted TAR or ZIP archive with excessive entries to exhaust the Java heap and hang the session. |
| Wasmtime 47.0.0 before 48.0.3 and 49.0.0 before 49.0.1 contains a fuel accounting flaw in Cranelift-compiled call_ref and try_table catch paths. Malicious guests can reset consumed fuel after calls to run exponentially long on linear fuel, evading timeouts and periodic yields for denial of service. |
| Mattermost versions 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 fail to limit the size of remote image responses buffered in memory during local image proxy direct fetches, which allows a remote attacker to cause memory exhaustion on the server via a crafted oversized image response.. Mattermost Advisory ID: MMSA-2026-00726 |
| Part-DB is an open source inventory management system for electronic components. Prior to version 2.13.2, Part-DB allows authenticated users to bypass the configured maximum attachment file size when using the server-side “Download external file” attachment feature. When server-side attachment downloads are enabled, Part-DB downloads the remote file and streams it directly to disk without enforcing the configured MAX_ATTACHMENT_FILE_SIZE limit. As a result, an authenticated user who can create or edit attachments can cause Part-DB to store files larger than the configured maximum attachment size, potentially exhausting disk space and causing a denial of service. This issue has been patched in version 2.13.2. |
| Part-DB is an open source inventory management system for electronic components. Prior to version 2.13.2, Part-DB allows authenticated API users to bypass the configured maximum attachment file size by uploading attachments through the API using base64-encoded file data. The application enforces the configured attachment size limit for normal browser-based file uploads, but the API base64 upload path does not apply the same size validation. As a result, an authenticated user with API access and permission to create attachments can upload files larger than the configured maximum attachment size, potentially exhausting disk space and causing a denial of service. This issue has been patched in version 2.13.2. |
| In the Linux kernel, the following vulnerability has been resolved:
serial: ma35d1: Fix clock reference leak in ma35d1serial_probe()
of_clk_get() returns a clock with a reference that has to be released
with clk_put(). ma35d1serial_probe() never does that, so the reference
is leaked on the probe error paths and also when the port is removed.
Release it on the error paths and in ma35d1serial_remove(). |
| cleanup_xml_node() in the SOAP XML parser recurses once per XML nesting level with no depth limit. An unauthenticated attacker can post a SOAP request containing tens of thousands of nested elements to any SoapServer endpoint, exhaust the stack and crash the process. The same unbounded recursion exists in the SOAP value decoder and in the WSDL node search helper. |
| undici is an HTTP client library for Node.js. In versions 6.5.0 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1, its EventSource client can be driven to exhaust process memory by a malicious or compromised Server-Sent Events peer. By sending millions of tiny completed data fields with no blank event separator, or a single unfinished line split across many chunks, the parser retains a growing amount of per-field and per-chunk state that the byte-based maxEventSize and maxResponseSize limits do not bound, and because maxResponseSize is enforced on the compressed body before decompression, a small compressed response can expand into enough retained memory to terminate the process. An application only needs to maintain an EventSource connection to an untrusted peer, which controls only the response, and availability is the only impact. The issue is fixed in undici 6.29.1, 7.30.1, and 8.12.2, which bound the retained parser state independently of the byte limits, and users should upgrade to one of those versions or later. There is no workaround. |
| react/http is an event-driven, streaming HTTP client and server implementation for ReactPHP. From 1.0.0 until 1.11.1, React\Http\Browser uses ClientRequestStream::handleData() to append response-header bytes to an internal buffer without enforcing a size limit. A remote server can send a valid status line and partial header, withhold the \r\n\r\n or \n\n header terminator, and continue streaming data so the buffer grows for the life of the connection. Applications that fetch attacker-controlled or attacker-influenced URLs, including URLs reached through redirects, can exhaust PHP memory_limit and crash the event-loop or worker process. Confidentiality and integrity are unaffected. This issue is fixed in version 1.11.1. |
