| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: digi_acceleport: fix memory corruption with small endpoints
Add the missing bulk-out buffer size sanity checks to avoid
out-of-bounds memory accesses or slab corruption should a malicious
device report smaller buffers than expected. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page
When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
to a PMD check failure, the pgtable allocated earlier via
pte_alloc_one() is never freed, causing a memory leak.
Added free_abort label to release the pgtable in error path. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: safe_serial: fix memory corruption with small endpoint
Make sure that the bulk-out buffer size is at least eight bytes to avoid
user-controlled slab corruption in "safe" mode should a malicious device
report a smaller size. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: cypress_m8: fix memory corruption with small endpoint
Make sure that the interrupt-out endpoint max packet size is at least
eight bytes to avoid user-controlled slab corruption or NULL-pointer
dereference should a malicious device report a smaller size. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: validate connector number in ucsi_connector_change()
The connector number in a UCSI CCI notification is a 7-bit field
supplied by the PPM. ucsi_connector_change() uses it to index the
ucsi->connector[] array without checking it against the number of
connectors the PPM reported at init time, so a buggy or malicious PPM
(EC firmware, or an I2C-attached UCSI controller on the ccg / stm32g0 /
glink transports) can drive schedule_work() on memory past the end of
the array.
Reject connector numbers that are zero or exceed cap.num_connectors
before dereferencing the array. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem
When a configuration file provides an object size that is larger than the
driver's known mxt_obj_size(object), the driver intends to discard the
extra bytes.
The loop iterates using for (i = 0; i < size; i++). Inside the loop, the
condition to skip processing extra bytes is:
if (i > mxt_obj_size(object))
continue;
Since i is a 0-based index, the valid indices for the object are 0 through
mxt_obj_size(object) - 1.
When i == mxt_obj_size(object), the condition evaluates to false, and the
code processes the byte instead of discarding it.
This causes the code to calculate byte_offset = reg + i - cfg->start_ofs
and writes the byte there, overwriting exactly one byte of the adjacent
instance or object.
Update the boundary check to skip extra bytes correctly by using >=. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: omninet: fix memory corruption with small endpoint
Make sure that the bulk-out buffers are at least as large as the
hardcoded transfer size to avoid user-controlled slab corruption should
a malicious device report a smaller endpoint max packet size than
expected. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()
iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes,
kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial
kref to 1. It then calls dma_resv_add_fence() which takes a second
reference (kref=2), and stores a raw pointer in block->fence.
On the success path the function returns without calling dma_fence_put()
to release the initial reference, so every buffer enqueue permanently
leaks one kmalloc-128 allocation.
The iio_buffer_cleanup() work item only releases the temporary reference
taken during completion signalling by iio_buffer_signal_dmabuf_done();
the initial reference from dma_fence_init() is never released.
With four iio_rwdev instances at 240kHz and 512 samples per buffer,
this produces ~1875 kmalloc-128 allocations per second matching the
observed slab growth exactly. A test with ftrace confirmed that the
dma_fence_destroy event was never triggered.
Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring
ownership of the fence to the DMA reservation object. The DMA fence then
gets properly discarded after being signalled. |
| The Redis protocol implementation in Apache bRPC allowed inline command parsing to allocate and copy the full connection buffer before a complete CRLF-terminated command was available. A remote attacker with access to a Redis-protocol bRPC service could send long inline inputs without a terminating CRLF to increase memory usage and CPU copy overhead, potentially causing denial of service.
Root Cause:
The Redis inline command parser allocated memory based on the current input buffer size and copied the entire buffer before determining the current inline command boundary. The existing redis_max_allocation_size limit was applied to RESP bulk strings and arrays, but not effectively to the inline command path before allocation.
Affected Scenarios:
Use Apache bRPC server with Redis protocol enabled and reachable by untrusted clients.
How to Fix:
1. Upgrade Apache bRPC to version 1.18.0, which fixes this issue.
2. Apply the patch from PR https://github.com/apache/brpc/pull/3363 .
Note:
The fix applies redis_max_allocation_size to Redis inline command lines and scans for CRLF before allocating parser arena memory. Inline command lines exceeding this limit are rejected. |
| The Redis server command parser in Apache bRPC accepts an empty RESP array as a command header. A remote unauthenticated attacker who can reach a bRPC server with Redis service enabled can send an empty array header followed by a bulk string, causing an out-of-bounds write in the parser and crashing the process.
Root Cause:
RedisCommandParser::ConsumeImpl rejected negative RESP array counts but accepted zero. It resized the command argument vector to zero elements and continued parsing. When a following bulk string was parsed, the only index guard was a CHECK. In configurations where fatal logs do not abort immediately, execution could continue and write to _args[0] even though the vector was empty.
Affected Scenarios:
Deployments that enable ServerOptions.redis_service and accept Redis protocol traffic from untrusted clients. The issue is reached during parsing before command handling or authentication.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3354
Note:
The fix rejects empty RESP arrays as invalid Redis commands and replaces the internal index CHECK with an explicit parse error so malformed command streams cannot fall through to an indexed vector write. |
| The RTMP AMF parser in Apache bRPC accepts AMF string lengths and array counts directly from untrusted input. A remote unauthenticated attacker who can reach a bRPC server with RTMP enabled can send a small AMF payload with an excessive declared long string length or array count, causing excessive memory allocation or resource consumption before the parser rejects the incomplete payload.
Root Cause:
The AMF long string parser resized the destination string to the declared 32-bit length before validating that the stream contained that many bytes. ECMA array and strict array parsers also accepted 32-bit element counts without a configurable upper bound.
Affected Scenarios:
Deployments that enable the bRPC RTMP server component and accept RTMP traffic from untrusted clients. Direct uses of the AMF parser on untrusted data are also affected.
How to Fix:
1. Upgrade bRPC to version 1.18.0, which fixes this issue.
2. Apply this patch: https://github.com/apache/brpc/pull/3353
Note:
The fix introduces configurable AMF parsing limits. The default maximum string size is 64 MiB and the default maximum array element count is 1,048,576. Payloads above these limits are rejected. The limits can be adjusted with amf_max_string_size and amf_max_array_size. |
| The Firelight Lightbox WordPress plugin before 2.3.23 does not escape the URL of links it opens in its Classic lightbox before inserting it into the page as HTML, which could allow users with a role as low as Contributor to perform Stored Cross-Site Scripting attacks against users who click a crafted link. |
| The BuddyForms WordPress plugin before 2.10.1 does not verify that a user editing an existing entry is the author of the target post, allowing users who have been granted edit access to a form, as low as Subscriber, to overwrite the title, content and status of any other user's posts or pages, including those of administrators. |
| The Joinchat WordPress plugin before 6.4.2 does not escape the message of its button block before outputting it in an HTML attribute on the front end, which could allow users with the Author role and above to perform Stored Cross-Site Scripting attacks against any visitor of the post, including administrators. |
| The WP Visitor Statistics (Real Time Traffic) WordPress plugin before 8.8 does not sanitize and escape tracking data derived from public visitor requests before storing it and outputting it in the administrative statistics dashboard, allowing unauthenticated attackers to inject arbitrary web scripts that execute when a logged-in administrator views the statistics pages. |
| The User Frontend WordPress plugin before 4.3.14 does not sanitise and escape some user-supplied values before reflecting them into HTML attributes in a publicly reachable AJAX response, leading to Reflected Cross-Site Scripting. The affected action is gated by an anonymous nonce that only validates for logged-out requests, so the payload executes against logged-out visitors rather than authenticated users. |
| Improper Neutralization of Special Elements used in an OS Command in Security Toolbox versions before 20260929 in Qingteng Host Adaptive Security Platform (Host Monitoring) V3.0 allows an authenticated console administrator to execute arbitrary commands on attached clients via OS command injection |
| Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself.
Impact:
The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation. |
| The nsenter --join-cgroup option opens the target cgroup.procs file as root and leaves that file descriptor open across later namespace and credential changes and across execve(). Because the kernel checks later cgroup migrations using the credentials from the original open, a program run in an attacker-controlled target can inherit root's ability to move host processes between cgroups. After a privileged operator uses --join-cgroup against that target, an unprivileged user can migrate and terminate unrelated root processes. |
| Adobe Experience Manager is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim's browser when they browse to the page containing the vulnerable field. Scope is changed. |
