| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper Validation of Specified Quantity in Input vulnerability in Ads by WPQuads Ads by WPQuads quick-adsense-reloaded allows Input Data Manipulation.This issue affects Ads by WPQuads: from n/a through <= 3.0.2. |
| Improper Validation of Specified Quantity in Input vulnerability in Ads by WPQuads Ads by WPQuads quick-adsense-reloaded allows Manipulating Hidden Fields.This issue affects Ads by WPQuads: from n/a through <= 3.0.2. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value by validating catalog record size
Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The
root cause is that hfs_brec_read() doesn't validate that the on-disk
record size matches the expected size for the record type being read.
When mounting a corrupted filesystem, hfs_brec_read() may read less data
than expected. For example, when reading a catalog thread record, the
debug output showed:
HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26
HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ!
hfs_brec_read() only validates that entrylength is not greater than the
buffer size, but doesn't check if it's less than expected. It successfully
reads 26 bytes into a 520-byte structure and returns success, leaving 494
bytes uninitialized.
This uninitialized data in tmp.thread.nodeName then gets copied by
hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering
the KMSAN warning when the uninitialized bytes are used as array indices
in case_fold().
Fix by introducing hfsplus_brec_read_cat() wrapper that:
1. Calls hfs_brec_read() to read the data
2. Validates the record size based on the type field:
- Fixed size for folder and file records
- Variable size for thread records (depends on string length)
3. Returns -EIO if size doesn't match expected
For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading
nodeName.length to avoid reading uninitialized data at call sites that
don't zero-initialize the entry structure.
Also initialize the tmp variable in hfsplus_find_cat() as defensive
programming to ensure no uninitialized data even if validation is
bypassed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: validate SVM ioctl nattr against buffer size
Validate nattr field against the buffer size, preventing
out-of-bounds buffer access via user-controlled attribute count.
(cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f) |
| Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses. |
| In the Linux kernel, the following vulnerability has been resolved:
net: remove WARN_ON_ONCE when accessing forward path array
Although unlikely, recent support for IPIP tunnels increases chances of
reaching this WARN_ON_ONCE if userspace manages to build a sufficiently
long forward path.
Remove it. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send
ib_uverbs_post_send() uses cmd.wqe_size from userspace without any
validation before passing it to kmalloc() and using the allocated
buffer as struct ib_uverbs_send_wr.
If a user provides a small wqe_size value (e.g., 1), kmalloc() will
succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge,
and other fields will read beyond the allocated buffer, resulting in
an out-of-bounds read from kernel heap memory. This could potentially
leak sensitive kernel information to userspace.
Additionally, providing an excessively large wqe_size can trigger a
WARNING in the memory allocation path, as reported by syzkaller.
This is inconsistent with ib_uverbs_unmarshall_recv() which properly
validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before
proceeding.
Add the same validation for ib_uverbs_post_send() to ensure wqe_size
is at least sizeof(struct ib_uverbs_send_wr). |
| In the Linux kernel, the following vulnerability has been resolved:
xen-netback: reject zero-queue configuration from guest
A malicious or buggy Xen guest can write "0" to the xenbus key
"multi-queue-num-queues". The connect() function in the backend only
validates the upper bound (requested_num_queues > xenvif_max_queues)
but not zero, allowing requested_num_queues=0 to reach
vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers
WARN_ON_ONCE(!size) in __vmalloc_node_range().
On systems with panic_on_warn=1, this allows a guest-to-host denial
of service.
The Xen network interface specification requires
the queue count to be "greater than zero".
Add a zero check to match the validation already present
in xen-blkback, which has included this
guard since its multi-queue support was added. |
| A flaw was found in gnutls. When validating certificates, an oversized Subject Alternative Name (SAN) could cause the validation process to incorrectly fall back to checking the Common Name (CN) field. This could allow a remote attacker to bypass proper certificate validation, potentially leading to spoofing or man-in-the-middle attacks. |
| Kysely is a type-safe TypeScript SQL query builder. From 0.26.0 to 0.28.16, DefaultQueryCompiler.visitJSONPathLeg does not escape JSON-path metacharacters (., [, ], *, **, ?). When attacker-controlled input flows into eb.ref(col, '->$').key(input) or .at(input) — including type-safe code where the JSON column is shaped like Record<string, T> so K extends string is the inferred type — every dot becomes a path-leg separator, letting an attacker traverse from the intended key into sibling and child fields the developer never meant to expose. The result is read access (and, in update statements, write access) to JSON sub-fields outside the intended scope across MySQL, PostgreSQL ->$/->>$, and SQLite. This vulnerability is fixed in 0.28.17. |
| A flaw was found in Keycloak. A remote attacker with high privileges, such as a realm administrator configuring a malicious Lightweight Directory Access Protocol (LDAP) server or an attacker compromising an upstream LDAP server, could exploit this vulnerability. By sending a malformed LDAP password policy response during a password authentication request, the attacker can trigger an OutOfMemoryError. This causes the Keycloak Java Virtual Machine (JVM) to terminate, leading to a denial of service (DoS) for all realms on the affected node. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix rxkad crypto unalignment handling
Fix handling of a packet with a misaligned crypto length. Also handle
non-ENOMEM errors from decryption by aborting. Further, remove the
WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can
still be emitted). |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: authencesn - reject short ahash digests during instance creation
authencesn requires either a zero authsize or an authsize of at least
4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of
high-order sequence number data at the end of the authenticated data.
While crypto_authenc_esn_setauthsize() already rejects explicit
non-zero authsizes in the range 1..3, crypto_authenc_esn_create()
still copied auth->digestsize into inst->alg.maxauthsize without
validating it. The AEAD core then initialized the tfm's default
authsize from that value.
As a result, selecting an ahash with digest size 1..3, such as
cbcmac(cipher_null), exposed authencesn instances whose default
authsize was invalid even though setauthsize() would have rejected the
same value. AF_ALG could then trigger the ESN tail handling with a
too-short tag and hit an out-of-bounds access.
Reject authencesn instances whose ahash digest size is in the invalid
non-zero range 1..3 so that no tfm can inherit an unsupported default
authsize. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs3: add buffer boundary checks to run_unpack()
run_unpack() checks `run_buf < run_last` at the top of the while loop
but then reads size_size and offset_size bytes via run_unpack_s64()
without verifying they fit within the remaining buffer. A crafted NTFS
image with truncated run data in an MFT attribute triggers an OOB heap
read of up to 15 bytes when the filesystem is mounted.
Add boundary checks before each run_unpack_s64() call to ensure the
declared field size does not exceed the remaining buffer.
Found by fuzzing with a source-patched harness (LibAFL + QEMU). |
| In the Linux kernel, the following vulnerability has been resolved:
ibmasm: fix OOB reads in command_file_write due to missing size checks
The command_file_write() handler allocates a kernel buffer of exactly
count bytes and copies user data into it, but does not validate the
buffer against the dot command protocol before passing it to
get_dot_command_size() and get_dot_command_timeout().
Since both the allocation size (count) and the header fields (command_size,
data_size) are independently user-controlled, an attacker can cause
get_dot_command_size() to return a value exceeding the allocation,
triggering OOB reads in get_dot_command_timeout() and an out-of-bounds
memcpy_toio() that leaks kernel heap memory to the service processor.
Fix with two guards: reject writes smaller than sizeof(struct
dot_command_header) before allocation, then after copying user data
reject commands where the buffer is smaller than the total size declared
by the header (sizeof(header) + command_size + data_size). This ensures
all subsequent header and payload field accesses stay within the buffer. |
| A flaw was found in Keycloak. An authenticated user with low privileges can exploit this vulnerability by sending an oversized subject_token JSON Web Token (JWT) to the TokenEndpoint. When the token exceeds a 4000-character limit, it is silently dropped, causing the system to fall back to client credentials. This allows the user to gain the permissions of the client's service account, leading to privilege escalation. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid5: validate payload size before accessing journal metadata
r5c_recovery_analyze_meta_block() and
r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a
journal metadata block using on-disk payload size fields without
validating them against the remaining space in the metadata block.
A corrupted journal contains payload sizes extending beyond the PAGE_SIZE
boundary can cause out-of-bounds reads when accessing payload fields or
computing offsets.
Add bounds validation for each payload type to ensure the full payload
fits within meta_size before processing. |
| In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: Add validation for MTU changes
Increasing the MTU beyond the HDS threshold causes the hardware to
fragment packets across multiple buffers. If a single-buffer XDP program
is attached, the driver will drop all multi-frag frames. While we can't
prevent a remote sender from sending non-TCP packets larger than the MTU,
this will prevent users from inadvertently breaking new TCP streams.
Traditionally, drivers supported XDP with MTU less than 4Kb
(packet per page). Fbnic currently prevents attaching XDP when MTU is too high.
But it does not prevent increasing MTU after XDP is attached. |
| IBM OPENBMC FW1110.00 through FW1110.11 is vulnerable to denial of service attacks by unauthenticated network users. |
| IBM Cloud APM, Base Private 8.1.4 and IBM Cloud APM, Advanced Private 8.1.4 IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in the data query logic of the Fenced environment. |
