CVE-2026-98453

What it actually does

SMB2_open accounts a successful CREATE response as an open handle before smb2_parse_contexts validates the create-context data; a parsing failure returns early without releasing the handle, leaving the server-side resource open and incrementing num_remote_opens without a corresponding close.

Why it matters to the business

Repeated trigger conditions can gradually exhaust SMB handle resources on Linux clients, degrading file-sharing performance and availability for applications that rely on SMB mounts until the kernel is updated.

How an attack unfolds

An attacker controlling an SMB server (or positioned as a man-in-the-middle) sends a CREATE response containing malformed create-context data; the client successfully records the open but then fails parsing and leaks the handle, allowing cumulative resource consumption without any authentication or privilege escalation required.

How to fix it

Apply the upstream Linux-kernel patch that closes the handle in the post-CREATE error path; rebuild or install the corrected kernel package for the affected distribution and reboot systems that mount SMB shares.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the SMB client source for the added close call after smb2_parse_contexts failure, or verify the running kernel version contains the commit that resolves the open-count imbalance.

Typical attack path

1. Establish an SMB session to a malicious or compromised server
2. Trigger SMB2 CREATE operations that include crafted create-context blobs
3. Cause smb2_parse_contexts to reject the data
4. Observe the client leaking the remote handle and inflating num_remote_opens
5. Repeat to accumulate resource pressure

How to detect it

Review kernel SMB client logs for repeated create-context parsing errors paired with handle accounting messages; correlate with process or connection counts that show num_remote_opens growing without corresponding closes on systems performing SMB operations.

What your security team should do

• Prioritize kernel updates on all Linux systems that act as SMB clients within the next maintenance window
• Monitor EPSS and exploit-maturity signals for any rise given the five-day publication window
• Audit SMB client configurations to ensure only trusted servers are contacted