| 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. |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco networking engineering team has conducted a comprehensive internal security review. This review resulted in a software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-76469 are related to insufficient control flow management issues that are grouped under the Common Weakness Enumeration (CWE) CWE-691. |
| Insufficient control flow management in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| Insufficient control flow management in the firmware for some Intel(R) Processors may allow an unauthenticated user to potentially enable escalation of privilege via physical access. |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco IOS XR Software engineering team has conducted a comprehensive internal security review. This review resulted in a software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-20276 are related to insufficient control flow management issues that are grouped under the Common Weakness Enumeration (CWE) CWE-691. |
| Insufficient control flow management in some Intel(R) TDX module software before version 1.5.05.46.698 may allow a privileged user to potentially enable denial of service via local access. |
| An issue was discovered in openRISC OR1200 commit 83ac6b. An inaccurate update of program counter (PC) values when SPR changes can lead to a Denial of Service (DoS). |
| Insufficient control flow management in DevTools in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco IOS XE Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-20271 are related to insufficient control flow management issues that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-691.
|
| Improper control flow management allows a crafted document action chain to cause modal dialog reentry on the main thread, resulting in UI freeze and denial of service. |
| Vyper is the Pythonic Programming Language for the Ethereum Virtual Machine. In versions up to and including 0.4.2rc1, `concat()` may skip evaluation of side effects when the length of an argument is zero. This is due to a fastpath in the implementation which skips evaluation of argument expressions when their length is zero. In practice, it would be very unusual in user code to construct zero-length bytestrings using an expression with side-effects, since zero-length bytestrings are typically constructed with the empty literal `b""`; the only way to construct an empty bytestring which has side effects would be with the ternary operator introduced in v0.3.8, e.g. `b"" if self.do_some_side_effect() else b""`. The fix is available in pull request 4644 and expected to be part of the 0.4.2 release. As a workaround, don't have side effects in expressions which construct zero-length bytestrings. |
| Insufficient control flow management in the Linux kernel-mode driver for some Intel(R) 700 Series Ethernet before version 2.28.5 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Insufficient control flow management in UEFI firmware for some Intel(R) Xeon(R) Processors may allow an authenticated user to enable denial of service via local access. |
| Insufficient control flow management in the Alias Checking Trusted Module for some Intel(R) Xeon(R) 6 processor E-Cores firmware may allow a privileged user to potentially enable escalation of privilege via local access. |
| Insufficient control flow management in some Intel(R) QAT Engine for OpenSSL software before version v1.6.1 may allow information disclosure via network access. |
| Insufficient control flow management for some Edge Orchestrator software for Intel(R) Tiber™ Edge Platform may allow a privileged user to potentially enable information disclosure via adjacent access. |
| Insufficient control flow management in the Linux kernel-mode driver for some Intel(R) 800 Series Ethernet before version 1.17.2 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Vyper is the Pythonic Programming Language for the Ethereum Virtual Machine. In versions up to and including 0.4.2rc1, the `slice()` builtin can elide side effects when the output length is 0, and the source bytestring is a builtin (`msg.data` or `<address>.code`). The reason is that for these source locations, the check that `length >= 1` is skipped. The result is that a 0-length bytestring constructed with slice can be passed to `make_byte_array_copier`, which elides evaluation of its source argument when the max length is 0. The impact is that side effects in the `start` argument may be elided when the `length` argument is 0, e.g. `slice(msg.data, self.do_side_effect(), 0)`. The fix in pull request 4645 disallows any invocation of `slice()` with length 0, including for the ad hoc locations discussed in this advisory. The fix is expected to be part of version 0.4.2. |
| Insufficient control flow management for some Intel(R) Xeon Processors may allow an authenticated user to potentially enable denial of service via local access. |
| Insufficient control flow management in the Alias Checking Trusted Module (ACTM) firmware for some Intel(R) Xeon(R) processors may allow a privileged user to potentially enable escalation of privilege via local access. |
