| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0, When a binding is created on an x-jms-topic exchange, add_binding/3 reads the rjms_erlang_selector argument and passes it through erl_scan:string/1 then erl_parse:parse_term/1. erl_scan:string/1 interns every atom literal it tokenizes. validate_binding/2 is a no-op (-> ok.), there is no length cap, and the surrounding try/catch cannot reclaim atoms. The Java JMS client compiles selectors client-side, but the server does not enforce this , a raw AMQP client can send arbitrary selector strings. An authenticated low-privilege AMQP user confined to one vhost can crash the entire broker node (cross-tenant DoS) in <100 bind calls. Preconditions include rabbitmq_jms_topic_exchange plugin enabled (bundled; required for any JMS deployment) Authenticated AMQP user with read on an x-jms-topic exchange + write on a queue (or configure to declare both). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, add_binding/3 parses the routing key as an integer weight N and computes ring positions with lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 only checks N >= 1 , no upper bound. The resulting list is stored in the exchange's Khepri record, replicated cluster-wide, and reloaded on restart. A user with write permission on a consistent-hash exchange and read on a queue can create a binding whose routing key (the hash-ring weight) is an arbitrarily large integer. The broker allocates a list of that many integers via lists:seq/2 and persists it to Khepri across all cluster nodes , a single binding with weight 100000000 allocates ~800 MB on every node and survives restarts. Preconditions include rabbitmq_consistent_hash_exchange plugin enabled write permission on a consistent-hash exchange + read on a queue (standard binding perms). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, get_chunk_selector/1 calls binary_to_atom on the raw client-supplied <<"chunk_selector">> property from post-auth subscribe and resolve_offset_spec frames, with no whitelist and no existing guard. An authenticated stream client with read access to any stream can crash the broker node. Preconditions include rabbitmq_stream plugin enabled Authenticated stream-protocol user with read access to at least one stream. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The stream open handler calls only check_vhost_access; it omits the node/vhost/user connection-limit checks that rabbit_reader performs for AMQP. A developer %% FIXME comment at the cited line explicitly acknowledges the gap. No compensating enforcement exists in connection tracking or elsewhere in rabbitmq_stream. An authenticated tenant can fully bypass operator-configured per-user and per-vhost connection caps by connecting via port 5552 instead of 5672. Preconditions include rabbitmq_stream plugin enabled Authenticated stream-protocol credentials Operator relies on per-user/per-vhost connection limits for tenant isolation. This issue is fixed in versions 4.2.7 and 4.3.1. |
| hpack is an HTTP/2 Header Encoding for Python. Prior to version 4.2.0, unbounded variable integer decoding can cause run-away computation on malformed input leading to O(n^2) runtime, effectively blocking further processing with large enough unsanitized input. A fix is available in python-hyper/hpack v4.2.0 to restricted variable integer decoding to uint32 to prevent run-away computation. As a workaround, sanitize input to hpack decoder for long sequences of `0xFF` values to prevent malicious use. |
| A vulnerability was determined in Netcore NBR200V2 1.3.241127.071246. This affects an unknown part of the file /www/cgi-bin/network_tools of the component CGI Diagnostic Endpoint. This manipulation of the argument param/key/val causes command injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in libsoup's WebSocket frame parsing implementation. The library fails to validate length rules specified in RFC 6455 ยง5.5, which mandates that all WebSocket control frames (e.g., PING, PONG, CLOSE) contain a payload of 125 bytes or less. A remote, unauthenticated attacker can exploit this by sending a non-compliant, oversized control frame. Because the parser handles this protocol violation improperly instead of throwing an immediate connection termination error, it triggers a internal processing crash, resulting in a remote denial of service (DoS) for applications utilizing libsoup WebSockets. |
| Improper restriction of recursive entity references in DTDs ('XML entity expansion') vulnerability in Apache Sling XSS.
This issue affects Apache Sling XSS: before 2.4.12.
Users are recommended to upgrade to version 2.4.12, which fixes the issue. |
| Robur Albatross 1.0.0 through 2.x before 2.7.2 does not limit use of the ring buffer, leading to an albatross-console loop with no recognized termination condition. This is only exploitable by users who can send console subscription commands to unikernels that produce sufficient log output to fill the ring buffer (1024 lines). It is not exploitable by unauthorized clients. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix buffer_head leak in ext4_init_orphan_info
ext4_init_orphan_info() reads orphan file blocks with ext4_bread()
and stores the returned buffer_head in oi->of_binfo[i].ob_bh.
If ext4_bread() succeeds but the orphan block magic or checksum
validation fails, the function jumps to out_free. However, the old
out_free loop starts releasing buffers from i - 1, so the current
buffer_head at index i is skipped.
This leaks the buffer_head reference obtained by ext4_bread() on the
bad magic and bad checksum error paths.
Fix this by tracking the number of successfully read buffer_heads and
releasing exactly those buffer_heads on the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: asus-wmi: fix resource leaks on probe failure
During driver initialization in asus_wmi_add(), various subsystems are
registered sequentially. However, the error path labels are out of order
relative to the registration sequence.
Specifically:
1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to
fail_custom_fan_curve. Because this label is placed below fail_sysfs,
it bypasses the cleanup calls for the input device and sysfs groups,
which were successfully registered before, leaking those resources.
2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad.
Because fail_screenpad is placed below fail_backlight, it bypasses the
cleanup calls for backlight and rfkill, leaking those resources.
Fix these resource leaks by reordering the error path labels in
asus_wmi_add() to match the exact reverse order of the resource
allocations. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix dc_lock leak on GPU reset error paths
On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume()
to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails,
the function returns with the lock still held. The matching resume path
is then skipped, so every later dc_lock take hangs.
Release the cached DC state and unlock before returning the error. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix BSG job leak on validate flash image error path
qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally,
telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver
owns and will complete the request. But bsg_job_done() is guarded by "if
(!rval)", so on the error path (rval == -EINVAL) neither the driver nor
the transport completes the job. The request dangles until it times out,
leaking block layer resources.
Commit c2c68225b145 ("scsi: qla2xxx: Fix bsg_done() causing double
free") added the "if (!rval)" guard to a batch of BSG handlers. That is
correct for handlers that also return the error code (the transport then
completes the job once via fail_host_msg), but this function returns
QLA_SUCCESS unconditionally, so the guard turned a correct single
completion into a leak.
Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is
reported in vendor_rsp[0], and since the function returns 0 the
transport will not complete the job a second time. |
| In the Linux kernel, the following vulnerability has been resolved:
media: intel/ipu6: fix async notifier cleanup leak on parse error
isys_notifier_init() calls v4l2_async_nf_init() and then adds fwnode
remote subdevs in a loop with v4l2_async_nf_add_fwnode_remote(). If an
endpoint parse or add fails partway through the loop, it jumps to
err_parse and returns without calling v4l2_async_nf_cleanup(), leaking
every v4l2_async_connection already added to the notifier's waiting
list.
The register-failure path just below already cleans up correctly, and
the caller only tears the notifier down (isys_notifier_cleanup()) once
isys_notifier_init() has returned success. Clean up the notifier on the
parse error path too. |
| In the Linux kernel, the following vulnerability has been resolved:
media: cec: core: Fix kmemleak due to missed rc_free_device() call
The commit dccc0c3ddf8f ("media: rc: fix race between unregister and
urb/irq callbacks") removed the implicit call to rc_free_device() from
rc_unregister_device(). However, the commit missed to remove the NULL
assignment of adap->rc that is now causing rc_free_device() to never be
called on an allocated rc device.
kmemleak reports following after e.g. dw-hdmi unbind:
unreferenced object 0xffff00010ac10000 (size 4096):
comm "kworker/u16:1", pid 39, jiffies 4294897739
hex dump (first 32 bytes):
20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K.............
08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................
backtrace (crc e11baccc):
kmemleak_alloc+0x38/0x44
__kmalloc_cache_noprof+0x4a8/0x5e0
rc_allocate_device+0x48/0x2a0
cec_allocate_adapter+0x3ac/0x800
dw_hdmi_cec_probe+0x264/0x634
platform_probe+0xc0/0x188
really_probe+0x4a4/0x8e0
__driver_probe_device+0x2f8/0x440
driver_probe_device+0x60/0x160
__device_attach_driver+0x1a0/0x2a0
bus_for_each_drv+0x100/0x1a0
__device_attach+0x174/0x350
device_initial_probe+0x90/0xb0
bus_probe_device+0x4c/0x120
device_add+0xdec/0x116c
platform_device_add+0x354/0x598
Remove the assignment of adap->rc to NULL to let cec_delete_adapter()
free the allocated rc device after last user of the cec device exits to
fix the kmemleak. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup
snd_ice1712_probe() performs multiple initialization steps after
snd_card_new(), but directly returns on failures from later steps
without releasing the ALSA card, causing resource leaks when
probing fails.
Use snd_devm_card_new() together with scope-based cleanup
via __free(snd_card_unref), and clear the card pointer after
successful registration to keep it alive. |
| Jawn is an open source JSON parser. Prior to 1.7.0, Jawn parse methods accept arbitrarily deep JSON array and object nesting without a depth limit, allowing a remote attacker who can submit untrusted JSON to grow parser contexts until the JVM heap is exhausted. The resulting java.lang.OutOfMemoryError is a fatal Scala error that is not ordinarily handled by scala.util.Try or cats.effect.IO, causing denial of service. This issue is fixed in version 1.7.0. |
| Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/replacer.go, resolving http.request.body reads the complete request body with an unbounded io.Copy before request-body middleware limits apply, allowing memory exhaustion and process termination. |
| Zapros, a Python HTTP client, prior to version 0.14.0 is vulnerable to denial of service when an application requests content from an untrusted server, or follows a redirect to one, because a malicious response containing an excessive number of chained `Content-Encoding` values causes Zapros to construct a deeply nested decompression chain that consumes excessive resources. Version 0.14.0 patches the vulnerability by limiting responses to five content-encoding layers and raising `DecodingError` when that limit is exceeded. As a workaround, applications can add response middleware that inspects the `Content-Encoding` header and rejects responses containing more than a safe number of encoding layers. |
| In NLnetLabs Unbound up to and including 1.26.0, a degradation of service vulnerability is present in the TCP/DoT reading procedure where there is no limit on consecutive reads. A malicious actor that can stream and sustain a rate of distinct uncached names over the TCP/DoT connection, monopolizes a single worker's entire event loop for as long as its writes stay ahead of the drain. |
