CVE-2026-52973General(linux / linux_kernel)

CVE-2026-43499,GhostLock: Linux kernel: Stack-UAF and LPE via futex in kernels 2.6.39 till 7.1 https://www.openwall.com/lists/oss-security/2026/07/08/12 Other recent futex bugs CVE-2026-23415, CVE-2026-31554, CVE-2026-52973 https://www.openwall.com/lists/oss-security/2026/07/09/1 All 4 have same CVSS 7.8 per kernel CNA https://x.com/nebusecurity/status/2074663573742338256

@nebusecurity Can you please bring this to oss-security, preferably with actual detail right in the posting (but do include the blog link as well). Maybe include your thoughts on / comparison to other recent futex bugs CVE-2026-23415, CVE-2026-31554, CVE-2026-52973 with same CVSS. Thank you!

A fixed kernel package sitting on disk does not protect the kernel currently in memory. For CVE-2026-52973, remediation only matters when the running kernel includes the distribution's fix. That sounds obvious, but stale runtimes remain common on hosts where reboot coordination is difficult. **In practical terms, it is a good time to:** - compare `uname -r` with installed kernel packages - identify hosts awaiting reboot after security updates - verify the expected kernel after restart #LinuxSecurity #PatchManagement #SysAdmin #KernelSecurity https://linuxsecurity.com/news/security-vulnerabilities/linux-futex-vfork-race

A kernel fix can be small in code and still expose a large assumption in architecture. The futex issue behind CVE-2026-52973 came from treating CLONE_THREAD as a proxy for the concurrency behavior that really mattered. The fix instead accounts for CLONE_VM sharing, with vfork() excluded because its execution semantics prevent the same race. That pattern appears throughout systems engineering: a convenient flag, group membership, service state, or configuration value becomes a stand-in for a property it does not fully guarantee. Over time, new execution paths invalidate the shortcut. **In practical terms, it is a good time to:** - review custom kernel-dependent software that uses unusual clone() flags or aggressive process creation - run representative concurrency and process-lifecycle tests after kernel updates on staging systems - inspect application crash reports for regressions involving threading, shared memory, or process creation - keep kernel and libc test coverage aligned with the production distributions you actually operate The broader takeaway is not “avoid assumptions.” It is to know which assumptions are acting as security boundaries. #KernelSecurity #OpenSourceSecurity #Linux #DevSecOps #InfrastructureSecurity https://linuxsecurity.com/news/security-vulnerabilities/linux-futex-vfork-race

“Local vulnerability” is one of the most misleading labels in infrastructure risk discussions. The NVD scoring for CVE-2026-52973 describes local attack access with low privileges. That sounds reassuring until you remember how many Linux systems intentionally provide local execution: CI runners, developer hosts, shared research servers, container platforms, bastion-adjacent tooling, and application nodes where a service account can execute code. Local does not mean harmless. It means the attacker needs a foothold first. In a real intrusion, that foothold may already exist through a web service, stolen SSH key, compromised dependency, or exposed container. A kernel memory-safety flaw can then become part of the path from limited execution to a much larger security outcome. **In practical terms, it is a good time to:** - identify systems where untrusted or semi-trusted users can execute local code - review SSH `authorized_keys`, sudo rules, and service accounts on those systems for unnecessary entry points - correlate kernel vulnerability exposure with EDR, auditd, or osquery evidence of unexpected local execution - prioritize remediation by workload trust model, not only by CVSS score Do your vulnerability priorities change when “local access” describes a normal feature of the platform rather than a rare prerequisite? #LinuxSecurity #PrivilegeEscalation #ThreatDetection #IncidentResponse #InfrastructureSecurity https://linuxsecurity.com/news/security-vulnerabilities/linux-futex-vfork-race

The hardest kernel bugs to investigate are often the ones that leave almost no useful evidence before the machine becomes unstable. CVE-2026-52973 was associated with a slab use-after-free condition detectable with KASAN. Most production systems do not run KASAN-enabled kernels, which means the clean diagnostic available to developers may be absent when an administrator sees a crash, lockup, or unexplained service failure. That gap matters for incident response. If kernel and early-boot logs are not retained off-host, a reboot can erase the context needed to distinguish hardware trouble, a kernel defect, and malicious activity. **In practical terms, it is a good time to:** - confirm `journald` or rsyslog forwards kernel messages to centralized storage - query recent logs for kernel oops, general protection faults, slab corruption, use-after-free indicators, or unexpected reboots - verify kdump is configured on systems where post-crash kernel evidence is operationally important - test whether crash dumps and kernel logs remain available after reboot and log rotation The useful takeaway is simple: kernel observability has to exist before the crash. #IncidentResponse #LinuxSecurity #SecurityOperations #KernelSecurity #SysAdmin https://linuxsecurity.com/news/security-vulnerabilities/linux-futex-vfork-race

Kernel races are often treated as obscure implementation bugs until they collide with a security boundary that everyone assumed was stable. CVE-2026-52973 is a useful example. The futex path relied on strict pthread-style `CLONE_THREAD` semantics when deciding whether to allocate private default hash state. But Linux can share an address space with `CLONE_VM` without using the exact thread model that assumption expected. Under the wrong interleaving, that mismatch can become a use-after-free. The operational lesson is broader than this one fix: kernel security depends on behavioral assumptions between subsystems, not just on whether an API is documented or a feature is enabled. Those assumptions are hard to see in an asset inventory, a benchmark, or a compliance report. For teams running dense multi-process workloads, container hosts, CI builders, or shared application platforms, concurrency bugs deserve attention because failure modes can cross availability and privilege boundaries quickly. **In practical terms, it is a good time to:** - compare the running kernel on exposed Linux systems with distribution advisories for CVE-2026-52973 - verify whether the distribution has backported the fix rather than relying only on upstream version numbers - inventory workloads that create many processes or share memory aggressively, especially on multi-tenant hosts - review kernel crash, oops, and KASAN-style evidence in centralized logs for unexplained memory-safety failures How often does your vulnerability process account for kernel backports and runtime behavior instead of just scanner version matching? #LinuxSecurity #KernelSecurity #VulnerabilityManagement #SysAdmin #DevSecOps https://linuxsecurity.com/news/security-vulnerabilities/linux-futex-vfork-race