| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched. As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list. Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb. The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb. Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker. |
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-82223 Reason: This candidate is a reservation duplicate of CVE-2026-82223. Notes: All CVE users should reference CVE-2026-82223 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. |
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-32566. Reason: This candidate is a reservation duplicate of CVE-2026-32566 Notes: All CVE users should reference CVE-2026-32566 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. |
| Driftregion iso14229 before 0.10.1 contains an integer wraparound in Handle_0x38_RequestFileTransfer that lets unauthenticated attackers bypass the file path length check. Attackers can send a short RequestFileTransfer (SID 0x38) request with filePathAndNameLength 0xFFFC-0xFFFF, causing callbacks to read past the receive buffer, crashing targets or disclosing memory. |
| Improper input validation in Desktop in Google Chrome prior to 155.0.8059.84 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration. |
| JIT miscompilation in the JavaScript Engine: JIT component. This vulnerability was fixed in Firefox 158, Firefox ESR 115.43, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| Incorrect boundary conditions in the JavaScript Engine component. This vulnerability was fixed in Firefox 158, Firefox ESR 115.43, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| Incorrect boundary conditions in the JavaScript Engine component. This vulnerability was fixed in Firefox 158, Firefox ESR 115.43, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| Sandbox escape due to uninitialized memory in the Graphics component. This vulnerability was fixed in Firefox 158, Firefox ESR 115.43, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| ELADMIN v2.7 and earlier contains an improper access control vulnerability in the user-management endpoint PUT /api/users/resetPwd of me.zhengjie.modules.system.rest.UserController. The method lacks the method-level authorization check applied to all other user-management endpoints and performs no role-level or ownership validation in UserServiceImpl.resetPwd. Any authenticated user of any role can reset the password of arbitrary users, including the built-in administrator. |
| An attacker could cause a heap buffer overflow by getting a user to open an email that is greater than or equal to 2GB in size. This vulnerability was fixed in Thunderbird 157, Thunderbird 140.17, and Thunderbird 153.4. |
| In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the MySQL message decoder aggregates inbound multi-packet payloads into a composite direct-memory buffer without any cumulative size limit. A malicious, compromised, or man-in-the-middle MySQL server can send a continuous stream of packets with the maximum payload length (0xFFFFFF), preventing the end-of-message condition from being reached, causing unbounded direct-memory allocation on the client and leading to an out-of-memory crash. This occurs before authentication completes.
The impacted component is io.vertx:vertx-mysql-client. |
| In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length.
This can be exploited for request smuggling purpose.
The impacted component is io.vertx:vertx-core. |
| In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the uniqueItems keyword validation uses an O(n²) pairwise comparison loop with no short-circuit or size limit. A remote unauthenticated attacker can submit a moderately-sized JSON array that consumes disproportionate CPU time, leading to denial of service.
The impacted component is io.vertx:vertx-json-schema.
The following Vert.x modules depend on vertx-json-schema and are also affected:
io.vertx:vertx-web-openapi-router io.vertx:vertx-web-validation io.vertx:vertx-openapi |
| SCM_RIGHTS file descriptor passing did not preserve FD_RESOLVE_BENEATH when a descriptor was transferred. A process could clear the restriction by sending the descriptor to itself over a Unix domain socket.
A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction. |
| renameat(2) did not enforce FD_RESOLVE_BENEATH on its directory arguments. A jailed process could rename a directory relative to a restricted descriptor, then escape the jail root via fchdir(2). This requires the directory to reside on a filesystem that is also reachable from the jail's root.
A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction. |
| The IPv6 UDP send path for unconnected sockets did not apply the jail policy of rewriting a loopback destination address to the jail's primary IPv6 address.
A process in a classic (non-VNET) jail can send UDP datagrams to services listening on the host's IPv6 loopback address, bypassing jail network isolation. |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. |
