https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-17T06:40:42.025716+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/cve-2026-43472 CVE-2026-43472 — unshare: fix unshare_fs() handling 2026-10-17T06:40:42.180310+00:00

Affected: Linux

In the Linux kernel, the following vulnerability has been resolved:

unshare: fix unshare_fs() handling

There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness]

> I guess if private means fs->users == 1, the condition could still be true.

Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS (and current->fs->users == 1).

We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts.

They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM _and_ leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug.

There is other fun related to that mess (races with pivot_root(), including the one between pivot_root() and fork(), of all things), but this one is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new fs_struct even if it h…

 https://cve.radiocsirt.org/vuln/usn-8567-1 USN-8567-1 — linux, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-realtime, linux-realtime-6.8 vulnerabilities 2026-10-17T06:40:42.180454+00:00

Affected: Ubuntu:22.04:LTS: linux-gcp-6.8, Ubuntu:Pro:Realtime:22.04:LTS: linux-realtime-6.8, Ubuntu:24.04:LTS: linux, Ubuntu:24.04:LTS: linux-gcp, Ubuntu:24.04:LTS: linux-gke, Ubuntu:24.04:LTS: linux-gkeop, Ubuntu:Pro:Realtime:24.04:LTS: linux-realtime

It was discovered that some AMD processors did not properly clear data in the floating point divider unit during speculative execution. A local attacker could use this to expose sensitive information. (CVE-2025-54505)

It was discovered that some AMD Zen 2 processors did not properly isolate shared resources in the operation cache. A local attacker could possibly use this issue to corrupt instructions executed at a higher privilege level, resulting in privilege escalation. (CVE-2025-54518)

It was discovered that some AMD Zen 5 processors supporting RDSEED instruction did not properly handle entropy, potentially resulting in the consumption of insufficiently random values. A local attacker could possibly use this issue to influence the values returned by the RDSEED instruction causing loss of confidentiality and integrity. (CVE-2025-62626)

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - Cryptographic API; - Compute Acceleration Framework; - ACPI drivers; - Serial ATA and Parallel ATA drivers; - Drivers core; - Power management core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - Compressed RAM block device driver; - Bluetooth drivers; - Bus devices; - Charact…