Latest Linux CVEs — 4 topics, fixes, pros & cons

Draft date: 2026-06-26 Scope: Four highest-signal CVE clusters currently in Canonical's Ubuntu Security Notice (USN) RSS feed, with the patched package, the pros of installing the fix, and the cons that should make an operator pause. Status: Longform content draft, handoff-ready. CVSS base scores are listed as unavailable where the upstream research run could not fetch the NVD detail page live (pipeline guard blocked NVD calls). CVE IDs and descriptions are sourced from the USN RSS itself, which is a primary distributor. This is a publishing draft, not a final advisory — see §5 for the human verification step before it goes live.

1. Why these four, and why now

The four topics below are the most recent high-impact clusters in the live USN feed at build time (2026-06-26T11:56:15Z). They were chosen because each one covers a different layer of the Linux stack — CPU microcode, container runtime, remote-access daemon, and core userspace utility — so a reader who patches all four exercises their full kernel-to-shell hygiene story in a single sitting. They were capped at four per the upstream brief; a fifth cluster (a second containerd CVE in USN-8472-1, plus several lower-severity kernel and glibc items) is omitted by design and listed in §6 for the next planning cycle.

Two honest framing notes before the four topics:

CVSS scores are unavailable in this draft. The pipeline that fed Alex's research brief could not reach nvd.nist.gov during the fetch window. NVD URLs are listed per CVE for the operator to score on their own workstation before publication. Do not invent scores.
One CVE ID is truncated in the upstream RSS payload — the tar CVE in §2.4 has its number marked unavailable — RSS payload truncated at fetch time. Resolve it from the USN-8477-1 page itself before this draft ships.

2. The four topics

2.1 AMD Microcode (USN-8475-1)

CVEs covered:

CVE-2024-36350 — store-inference side channel on AMD processors
CVE-2024-36357 — related AMD store-leakage side channel
CVE-2025-62626 — RDSEED entropy weakness on AMD Zen 5

What it is (paraphrased from USN-8475-1): local attackers can infer data from prior CPU stores (36350 / 36357) and bias RDSEED output on Zen 5 silicon (62626), leading to confidentiality and integrity loss on AMD-powered Linux hosts. This is a CPU-level issue, not an OS bug — the OS just ships the firmware blob that mitigates it.

Fix: update the amd64-microcode package to the patched build Canonical lists per Ubuntu LTS line. intel-microcode is a separate package and is not affected by this USN.

Pros of patching	Cons of patching
Closes a CPU-level data-leakage channel that survives OS reinstallation. The fix has to live in microcode, not in the kernel, so a kernel-only patch would not address it.	Requires a reboot to load the new microcode. Rolling clusters see a staggered exposure window if reboots are paced, and high-density hosts may take 5–15 minutes to come back depending on memory size.
Required to keep Ubuntu LTS under active vendor support — running unpatched microcode past the USN date means you are off the supported configuration matrix.	The RDSEED bias (62626) is a probabilistic attack. Servers without sensitive cross-process secrets (single-tenant build hosts, public web frontends) may not justify the reboot cost in the short term.
No application-level service restart of running workloads. Microcode loads at next boot and is transparent to userspace.	Newer microcode has, historically, occasionally regressed idle power and turbo behaviour on specific SKUs. Pin and monitor with `powertop` / `turbostat` on a canary before fleet rollout.

Verdict: patch within the next standard maintenance window. Do not defer past the next reboot cycle. Pin and monitor one host per SKU for 24h before broad rollout.

Primary sources: https://ubuntu.com/security/notices/USN-8475-1 ; https://nvd.nist.gov/vuln/detail/CVE-2024-36350 ; https://nvd.nist.gov/vuln/detail/CVE-2024-36357 ; https://nvd.nist.gov/vuln/detail/CVE-2025-62626

2.2 containerd (USN-8472-1)

CVEs covered:

CVE-2026-33814 — HTTP/2 SETTINGS-frame infinite-loop DoS in containerd
(A second containerd CVE in the same USN covers a group-parse error during container creation. Its identifier was truncated in the upstream RSS payload and is marked unavailable in this draft — pull it from the USN-8472-1 page before publishing.)

What it is: a remote attacker can send crafted HTTP/2 SETTINGS frames to drive containerd into an infinite loop, causing a denial of service. The second, group-parse issue is a separate failure mode during container creation; treat both as in-scope for the same patch window.

Fix: update the containerd package (and containerd.io / runc as bundled) to the patched versions Canonical lists per Ubuntu release. A systemctl restart containerd plus a pod reschedule is required to load the new runtime.

Pros of patching	Cons of patching
DoS in the container runtime is a single fix-point that takes down every workload on a host. High blast radius, low patch cost — one package update neutralises the whole class.	Container runtime upgrades need a `systemctl restart containerd` and a drain / reschedule of pods in Kubernetes. Brief disruption on each node, multiplied across the node pool.
Patched packages are drop-in. No config changes, no image rebuild, no manifest edits required.	The HTTP/2 DoS is reachable only by network-adjacent attackers. Hosts behind a service mesh, an ingress controller, or a private VPC are at lower immediate risk and can be scheduled into a lower-priority window.
Fixes a class of bug (HTTP/2 control-frame handling) that is structurally similar to historical issues in other Go HTTP/2 stacks. Closing it now reduces the chance of a related CVE landing next month.	Requires coordinated drain across the node pool. On a 50-node cluster this is a planned maintenance event, not a same-day push.

Verdict: patch inside the next planned Kubernetes maintenance window (most teams run these weekly). For hosts with public ingress exposing containerd's debug port, patch within 72 hours.

Primary sources: https://ubuntu.com/security/notices/USN-8472-1 ; https://nvd.nist.gov/vuln/detail/CVE-2026-33814

2.3 xrdp (USN-8476-1)

CVEs covered:

CVE-2025-68670 — bounds-check failure in user-domain handling during xrdp connection sequence (DoS, possible RCE)
CVE-2024-39917 — MaxLoginRetry bypass (unlimited login attempts)
CVE-2023-42822 — out-of-bounds read on font-glyph data (Ubuntu 24.04 LTS only)
CVE-2023-40184 — session-establishment error handling bypasses PAM restrictions (Ubuntu 24.04 LTS only)

What it is: an unauthenticated remote attacker can crash xrdp and possibly execute arbitrary code via the user-domain handling path; rate-limiting and PAM session controls are also bypassable. The chain of 68670 (domain bounds) plus 42822 (font-glyph OOB) is the realistic path toward code execution on a fully-patched pre-68670 host.

Fix: update the xrdp package. Patch is per-Ubuntu-release and is identical across all supported LTS lines except for the 42822 / 40184 pair, which only affect 24.04 LTS.

Pros of patching	Cons of patching
CVE-2025-68670 is pre-auth and reachable from any exposed RDP port. This is the highest-severity item in the four-topic set and the one to act on first.	xrdp is internet-facing in some fleets. Blue/green rollout is hard because users hold active sessions, and an upgrade that drops sessions is a user-visible incident.
Closes a chain where font-glyph OOB read (42822) plus domain-bounds failure (68670) could combine toward code execution. Patching both at the same time breaks the chain.	The older CVEs (2023-42822, 2023-40184) only affect Ubuntu 24.04 LTS. Readers on 22.04 / 20.04 do not need to act on those two and may be confused by the noise — flag the applicability in the customer-facing version.
PAM bypass (40184) is a clean, single-package fix. It does not require coordination with any auth-backend change.	Restart of xrdp drops every active RDP session at the moment of upgrade. Schedule the upgrade during a low-usage window, or warn users in advance.

Verdict: patch within 72 hours for any host with xrdp exposed beyond localhost. For 24.04 LTS hosts the four-CVE picture is a strict superset of the 22.04 picture and the urgency is the same.

Primary sources: https://ubuntu.com/security/notices/USN-8476-1 ; https://nvd.nist.gov/vuln/detail/CVE-2025-68670 ; https://nvd.nist.gov/vuln/detail/CVE-2024-39917 ; https://nvd.nist.gov/vuln/detail/CVE-2023-42822 ; https://nvd.nist.gov/vuln/detail/CVE-2023-40184

2.4 tar (USN-8477-1)

CVEs covered:

A single tar CVE — number truncated in the upstream RSS payload and marked unavailable in this draft. Pull the exact identifier from https://ubuntu.com/security/notices/USN-8477-1 before publishing.

What it is: tar mishandles certain crafted archive files so that an attacker can inject hidden files with attacker-controlled content, bypassing pre-extraction inspection mechanisms. This is a post-extraction integrity / path-spoofing class issue, not a code-execution primitive by itself.

Fix: update the tar package to the patched version listed in USN-8477-1. Filesystem-only operation; no service restart.

Pros of patching	Cons of patching
Tar is on every Linux host and is used by almost every backup / restore / package-extraction workflow. Patching is cheap — one package, one `apt upgrade`.	Extraction-time bypass means an attacker needs the victim to actually unpack a malicious archive. Narrower threat model than a network-facing CVE; defenders who never extract untrusted archives are not exposed.
Closes a class of bypass against the very inspection tools defenders use to look at archives before extraction. Patching the underlying util is more durable than wrapping every extraction site.	Tar being such a core util, regressions in extraction behaviour can silently break backup pipelines. Test restores on a canary before fleet rollout — `tar --compare` against a known-good snapshot is a 30-second check.
No service restart. Filesystem-only operation. Safe to roll out in the same window as the microcode reboot.	CVE number for the specific tar issue is `unavailable — RSS payload truncated at fetch time`. Consult the USN-8477-1 page directly before publication.

Verdict: patch in the next routine maintenance window. It is cheap to roll out and removes a class of attack that is hard to defend against at the workflow level. Do test a restore on at least one canary host.

Primary sources: https://ubuntu.com/security/notices/USN-8477-1

3. Side-by-side summary

#	Topic	USN	CVEs	Patch command (Ubuntu)	Urgency	Disruption
1	AMD Microcode	USN-8475-1	36350, 36357, 62626	`apt install --only-upgrade amd64-microcode`	Standard window	Reboot
2	containerd	USN-8472-1	33814 (+1 truncated)	`apt install --only-upgrade containerd` then `systemctl restart containerd`	Next K8s window (72h if exposed)	Drain + reschedule
3	xrdp	USN-8476-1	68670, 39917, 42822, 40184 (*24.04 only)	`apt install --only-upgrade xrdp` then `systemctl restart xrdp`	72h if exposed	Session drop
4	tar	USN-8477-1	1 (ID unavailable)	`apt install --only-upgrade tar`	Routine window	None (test restores)

4. Operator checklist before publishing this draft

1. Resolve the two unavailable items. Fetch https://ubuntu.com/security/notices/USN-8477-1 to get the tar CVE identifier, and re-pull https://ubuntu.com/security/notices/USN-8472-1 for the truncated second containerd CVE. Do not ship with unavailable placeholders in the customer-facing version. 2. Add CVSS base scores from NVD. Open each NVD URL listed in §2 from a workstation that can reach nvd.nist.gov and fill in the score per CVE. These were unavailable to the upstream research run. 3. Confirm Ubuntu-version applicability for the 42822 / 40184 pair (24.04 LTS only) before the customer-facing version goes out, so readers on 22.04 / 20.04 do not chase fixes that do not apply to them. 4. Sanity-check the urgency column in §3 against your own infrastructure exposure (public RDP, public containerd debug port, AMD Zen 5 fleet, etc.) and adjust the per-environment window before this is sent to a customer.

5. What this draft is, and what it is not

This is a publishing draft, not a Canonical advisory and not a vendor CVE feed. The upstream research brief (workspace/alex/cve-linux-brief-2026-06-26.md) is the source of truth for CVE IDs and USN references; the operator checklist in §4 is the source of truth for what still needs a human before this is ready to ship. Treat §1–§3 as content that is safe to publish once §4 is cleared, and treat the "unavailable" markers in §2.2, §2.4, and §3 as hard placeholders — not as facts to copy forward.

6. Items intentionally left out of the four-topic cap

USN-8472-1 carries a second containerd CVE (group-parse) whose ID was truncated in the RSS payload and is marked unavailable — RSS payload truncated at fetch time. Resolve and add to a follow-up post if reader demand is there.
The repo's cached workspace/alex/nvd-linux.json (build date 2026-06-22, 20 items, mostly historical e.g. CVE-2001-1391) was not used as a primary source; the live USN RSS supersedes it.
A handful of lower-severity kernel and glibc items from the same feed window were dropped to keep the customer-facing piece at four topics. Re-surface them in a follow-up "lower-severity tail" post rather than expanding this one.