Threats Tagged 'cve-2026-46300'
View all threats tagged with 'cve-2026-46300'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-46300'
Click on any threat for detailed analysis and mitigation recommendations
0 Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.12.91. See the following advisory for the RPM packages for this release: https://access.redhat.com/errata/RHBA-2026:21694 Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes: https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html/release_notes Security Fix(es): None For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.12 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.12/html-single/updating_clusters/index#updating-cluster-within-minor. Join the discussion | GCVE Database | 06/04/2026, 17:00:30 UTC Added: 05/28/2026, 22:15:03 UTC |
0 The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: proc: fix UAF in proc_get_inode() (CVE-2025-21999) * kernel: Linux kernel (qla2xxx): Double free vulnerability leads to denial of service and potential privilege escalation. (CVE-2025-71238) * kernel: Linux kernel: Denial of service and memory corruption in RDMA umad (CVE-2026-23243) * kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401) * kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532) * kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300) * kernel: Read root-owned files as an unprivileged user (CVE-2026-46333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 05/26/2026, 06:06:21 UTC Added: 05/26/2026, 20:58:45 UTC |
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Join the discussion | GCVE Database | 05/23/2026, 12:17:00 UTC Added: 07/18/2026, 11:18:20 UTC |
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. Join the discussion | GCVE Database | 05/23/2026, 12:17:00 UTC Added: 07/16/2026, 10:38:46 UTC |
0 The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300) * kernel: Read root-owned files as an unprivileged user (CVE-2026-46333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 05/21/2026, 18:10:43 UTC Added: 05/26/2026, 20:58:01 UTC |
0 The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300) * kernel: Read root-owned files as an unprivileged user (CVE-2026-46333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 05/21/2026, 14:50:43 UTC Added: 05/27/2026, 21:15:49 UTC |
0 The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532) * kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300) * kernel: Read root-owned files as an unprivileged user (CVE-2026-46333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 05/21/2026, 12:41:53 UTC Added: 07/18/2026, 11:22:59 UTC |
0 The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements. Security Fix(es): * kernel: proc: fix UAF in proc_get_inode() (CVE-2025-21999) * kernel: Linux kernel (qla2xxx): Double free vulnerability leads to denial of service and potential privilege escalation. (CVE-2025-71238) * kernel: Linux kernel: Denial of service and memory corruption in RDMA umad (CVE-2026-23243) * kernel: Linux kernel KVM: Privilege escalation or denial of service due to improper shadow page table entry handling (CVE-2026-23401) * kernel: can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532) * kernel: "Fragnesia" is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel (CVE-2026-46300) * kernel: Read root-owned files as an unprivileged user (CVE-2026-46333) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 05/20/2026, 23:40:26 UTC Added: 05/26/2026, 20:58:01 UTC |
Red Hat® AI Inference Server Join the discussion | GCVE Database | 05/20/2026, 16:21:18 UTC Added: 05/27/2026, 21:15:26 UTC |
Red Hat® AI Inference Server Join the discussion | GCVE Database | 05/20/2026, 16:20:16 UTC Added: 05/27/2026, 21:15:26 UTC |
Showing 1 to 10 of 21 results