Upstream linux-hardened tag v7.1.3-hardened1 available #22

New issue

Closed

opened 2026-07-09 23:01:24 +00:00 by unredacted_bot · 1 comment

unredacted_bot commented

2026-07-09 23:01:24 +00:00

Owner

Upstream tag: v7.1.3-hardened1
Local latest: v7.1.2-hardened1

CVEs reported fixed in 7.1.3 since 7.1.2 (source: kernel.org CVE project).

Severity = Red Hat's rating (best-effort; the kernel CNA publishes no CVSS), not the project's own. List as of 2026-07-09T23:01Z — the feed can lag, so re-check vulns.git before building.

CVE-2026-53359 — Important (CVSS 7.8) — 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.
…

CVE-2026-53362 — Important (CVSS 7.8) — 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
…

Action: review the upstream signature, then push a matching
local tag (git tag v7.1.3-hardened1 && git push origin v7.1.3-hardened1)
which triggers build-kernel.yml.

See docs/users/cve-policy.md for the SLA.

Upstream tag: v7.1.3-hardened1 Local latest: v7.1.2-hardened1 **CVEs reported fixed in `7.1.3` since `7.1.2`** (source: kernel.org CVE project). _Severity = Red Hat's rating (best-effort; the kernel CNA publishes no CVSS), not the project's own. List as of 2026-07-09T23:01Z — the feed can lag, so re-check vulns.git before building._ <details><summary><strong>CVE-2026-53359</strong> — Important (CVSS 7.8) — KVM: x86: Fix shadow paging use-after-free due to unexpected role</summary> ```text 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. … ``` </details> <details><summary><strong>CVE-2026-53362</strong> — Important (CVSS 7.8) — ipv6: account for fraggap on the paged allocation path</summary> ```text 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 … ``` </details> Action: review the upstream signature, then push a matching local tag (`git tag v7.1.3-hardened1 && git push origin v7.1.3-hardened1`) which triggers build-kernel.yml. See docs/users/cve-policy.md for the SLA.

zach commented

2026-07-10 07:07:05 +00:00

Owner

Released

zach closed this issue

2026-07-10 07:07:05 +00:00

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

unredacted/linux-hardened-unredacted#22

No description provided.

Rows
Columns