Skip to main content

Threats Tagged 'cve-2026-53366'

View all threats tagged with 'cve-2026-53366'. Filter and sort to focus on specific types of threats.

Pro Console Lifetime

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)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (1):Tag: cve-2026-53366

Threats Tagged 'cve-2026-53366'

Click on any threat for detailed analysis and mitigation recommendations

In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

Join the discussion

This update for the SUSE Linux Enterprise Kernel 6.12.0-160000.5.1 fixes various security issues: The following security issues were fixed: - CVE-2026-23240: tls: Fix race condition in tls_sw_cancel_work_tx() (bsc#1262404). - CVE-2026-31738: vxlan: validate ND option lengths in vxlan_na_create (bsc#1264060). - CVE-2026-43038: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() (bsc#1271648). - CVE-2026-46113: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN (bsc#1266970). - CVE-2026-53359: KVM: x86: Fix shadow paging use-after-free due to unexpected role (bsc#1270060). - CVE-2026-53366: ipv4: account for fraggap on the paged allocation path (bsc#1271370).

Join the discussion

This update for the SUSE Linux Enterprise Kernel 6.12.0-160000.28.1 fixes various security issues: The following security issues were fixed: - CVE-2026-31738: vxlan: validate ND option lengths in vxlan_na_create (bsc#1264060). - CVE-2026-43038: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() (bsc#1271648). - CVE-2026-46113: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN (bsc#1266970). - CVE-2026-53359: KVM: x86: Fix shadow paging use-after-free due to unexpected role (bsc#1270060). - CVE-2026-53366: ipv4: account for fraggap on the paged allocation path (bsc#1271370).

Join the discussion

This is a kernel live patch module which can be loaded by the kpatch command line utility to modify the code of a running kernel. This patch module is targeted for kernel-4.18.0-553.53.1.el8_10. Security Fix(es): * kernel: KVM: x86: Fix shadow paging use-after-free due to unexpected role (CVE-2026-53359) 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
0

These are all security issues fixed in the kernel-devel-7.1.4-1.1 package on the GA media of openSUSE Tumbleweed.

Join the discussion
0

These are all security issues fixed in the kernel-devel-7.1.4-1.1 package on the GA media of openSUSE Tumbleweed.

Join the discussion

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.

Join the discussion

In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

Join the discussion

Showing 1 to 8 of 8 results

Filters:Tag: cve-2026-53366
Page 1 of 1
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses