What is the CVSS score of CVE-2024-53095?

CVE-2024-53095 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

How to fix or mitigate CVE-2024-53095?

Within 24 hours, identify all systems running affected Linux kernel versions with active CIFS mounts, particularly in containerized or non-root namespace environments, and assess current kernel versions. Within 7 days, deploy vendor-released patches (Linux kernel 6.12+ or apply stable backports to your specific kernel version) to all identified systems, coordinating updates during maintenance windows to minimize service disruption. Within 30 days, conduct verification that all affected systems have been patched and are running secure kernel versions; update patch management procedures to accelerate deployment of critical kernel security updates.

Linux Kernel CVE-2024-53095

CRITICAL

Use After Free (CWE-416)

2024-11-21 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Information Disclosure Linux Kubernetes Use After Free Memory Corruption

9.8

CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Gain privilege to manage netns and CIFS mounts
Delivery

Mount CIFS share in non-root netns
Exploit

Induce packet loss to force reconnect
Execution

Destroy netns while cifsd reconnecting
Persist

Trigger use-after-free in FIB lookup
Impact

Kernel oops / potential memory corruption

Vulnerability Assessment

Weakness	CWE CWE-416 ASVS 5.0 V15 - Secure Coding and Architecture Memory lifecycle management MITRE ATT&CK 2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Requires a CIFS/SMB share mounted inside a non-root network namespace (the Kubernetes/container use case), the local privilege to create and destroy that netns and to mount/unmount CIFS (effectively CAP_SYS_ADMIN), and a triggering sequence in which the netns is destroyed while the CIFS client is mid-reconnect (induced by packet loss/server unresponsiveness) followed by unmount. Limiting factors: exploitation is local and privileged rather than remote-unauthenticated despite the CVSS AV:N rating, it is a timing-dependent race the report describes as rarely occurring and only during teardown, and it is only reachable on hosts that actually run CIFS mounts in non-root netns; default single-namespace CIFS mounts are not affected. The splat is most readily observed with CONFIG_NET_NS_REFCNT_TRACKER enabled.
Impact	The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, 9.8 Critical) substantially overstates real-world risk and is inconsistent with the described exploitation path. The bug is a race triggered by a very specific local operational sequence - mount CIFS in a non-root netns, cause packet loss, destroy the netns, then unmount - which requires the ability to create/destroy network namespaces and mount filesystems (effectively CAP_SYS_ADMIN), not an anonymous remote attacker. The description itself states the problem 'rarely happened' and only during teardown, indicating a hard-to-win race (AC:H). Corroborating signals reinforce lower priority: EPSS is 0.22% (13th percentile), the CVE is not in CISA KEV, and no POC is referenced. The realistic impact is a denial of service (kernel oops) with a use-after-free that could in principle be steered toward memory corruption, but there is no evidence of practical code execution. Conflict to note explicitly: CVSS advertises network vector and no privileges, yet the actual trigger is local, privileged, and race-dependent - treat the 9.8 as an automated NVD scoring artifact and prioritize based on whether you run containerized CIFS mounts in non-root netns.
Exploit ScenarioDerived	A tenant workload with permission to create network namespaces and mount CIFS (e.g., a privileged Kubernetes pod) mounts an SMB share in a non-root netns, then induces packet loss to the server so the client enters reconnect, and destroys the netns while cifsd is still trying to reconnect and unmounts the share. The reconnect thread dereferences the freed network namespace during routing lookup, crashing the host kernel (DoS); no public exploit code is identified, and reliably winning the race for anything beyond a crash would be difficult.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Aug 04, 2026

Use-after-free of a network namespace in the Linux kernel's SMB/CIFS client (cifs.ko) allows a kernel crash and potential memory corruption when a CIFS mount lives in a non-root network namespace that is torn down while the client is reconnecting. Because CIFS uses kernel TCP sockets that do not hold a reference on their netns, the cifsd reconnect thread can call into routing/FIB code (fib_rules_lookup) against an already-freed netns, producing an oops. A vendor patch is available (fix merged for 6.12 and backported to stable); this is CWE-416 and there is no public exploit identified at time of analysis, with a low EPSS score of 0.22%.

RemediationAI

Apply the kernel update containing the fix: the change was merged for 6.12 and backported to stable trees via commits c7f9282fc27f, e8c714941811, and ef7134c7fc48 (see the git.kernel.org links) - upgrade to the patched stable release provided by your distribution that incorporates these commits (Vendor-released patch available per the stable git advisories; consume your distro's fixed build rather than an unversioned tag). If you cannot patch immediately, reduce exposure by not mounting CIFS/SMB shares inside non-root (per-pod/per-container) network namespaces - mount in the host/root netns instead, which removes the teardown race at the cost of losing netns-scoped routing for the share. Alternatively, avoid destroying network namespaces while CIFS mounts remain active by ensuring shares are cleanly unmounted before pod/netns teardown, and restrict the CAP_SYS_ADMIN capability needed to create netns and mount filesystems to trusted workloads, accepting the operational constraint that pods can no longer self-manage namespaced mounts.

Affects your stack

Find out whether the stacks and servers you run are on an affected version.

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The affected component is the in-kernel SMB client (fs/smb/client, cifs.ko), which establishes its transport over kernel-mode TCP sockets. Kernel sockets, unlike user sockets, do not take a refcount on the network namespace (struct net) they belong to, so the CIFS layer must guarantee the socket is destroyed before its netns. The root cause (CWE-416, use-after-free) is missing reference counting: when a CIFS mount runs in a non-root netns (a common Kubernetes pattern where pods mount SMB shares) and that netns is destroyed while sockets are still alive, the async TCP timers and the cifsd reconnect path (cifs_demultiplex_thread → generic_ip_connect → __sock_create → tcp_v4_connect → __fib_lookup) dereference the freed net structure. The fix mirrors the SMC fix (commit 9744d2bf1976) by holding a netns refcnt per socket via maybe_get_net(), and moves put_net() from cifs_put_tcp_session() to clean_demultiplex_info() so reconnect attempts cannot touch a freed netns. Affected CPEs point at Linux kernel 6.12 release candidates (rc1-rc6), though the latent bug predates that window.

Know when Kubernetes gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY 9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI 4.1 MEDIUM

Local privileged operations (mount CIFS, create/destroy netns → CAP_SYS_ADMIN) drive AV:L and PR:H; the rare teardown race gives AC:H; realistic impact is a kernel crash, so A:H with C:N/I:N.

3.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H

4.0 AV:L/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Aug 04, 2026 - 11:30 vuln.today

v1 - CVSS changed

Severity Changed

Aug 04, 2026 - 11:23 NVD

HIGH CRITICAL

CVSS changed

Aug 04, 2026 - 11:23 NVD

7.8 (HIGH) 9.8 (CRITICAL)

CVE Published

Nov 21, 2024 - 19:15 cve.org

HIGH 7.8

DescriptionCVE.org

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

smb: client: Fix use-after-free of network namespace.

Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0]

The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying.

The root cause is wrong reference counting for network namespace.

CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.

The repro steps are roughly:

mount CIFS in a non-root netns
drop packets from the netns
destroy the netns
unmount CIFS

We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.

When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.

Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").

Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().

Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.

[0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---

Executive ViewAI

Why It Matters

A use-after-free vulnerability in Linux kernel's CIFS client (CVE-2024-53095, CVSS 9.8) can crash the kernel or corrupt memory when CIFS mounts in non-root network namespaces are torn down during reconnection. Organizations running CIFS in containerized or virtualized environments face potential service interruptions and system instability; this requires priority remediation due to its critical severity.

Business Impact: Severe

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.2%

Top 87% exploitable

Prevalence

Ubiquitous

Linux kernel CIFS client; runs on a huge fraction of servers and containers

Data Quality

3 sources

Confidence: Low

NVD

CVE.org

EPSS

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity CRITICAL

CISA KEV No

Public POC No

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

CRITICAL severity

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Out-of-Cycle

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Yes

Human Impact

Very High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +49

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Use After Free HIGH

Use-after-free vulnerabilities occur when a program continues to access memory through a pointer after that memory has been deallocated.

Memory Corruption HIGH

Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.