CVE-2023-32258

What it actually does

Race condition in ksmbd due to missing locking during SMB2_LOGOFF and SMB2_CLOSE command processing enables attacker-controlled operations on kernel objects that culminate in arbitrary code execution in kernel context.

Why it matters to the business

Unpatched Linux systems exposing the in-kernel SMB server face risk of remote kernel compromise, which can result in full host takeover, persistence, or lateral movement; the 1180-day-old issue has low current exploitation probability but still requires attention on any remaining ksmbd deployments.

How an attack unfolds

An attacker connects to the ksmbd server over SMB, then issues concurrent or precisely timed SMB2_LOGOFF and SMB2_CLOSE requests that exploit the missing lock to corrupt internal kernel object state and redirect execution to attacker-supplied code.

How to fix it

Upgrade the Linux kernel to the commit 5729a900a07b7f166b94577c543d44c4c42e5ec3 or later; disable ksmbd if SMB server functionality is not required.

How to confirm the fix worked

Verify the running kernel contains commit 5729a900a07b7f166b94577c543d44c4c42e5ec3; review ksmbd source for presence of the required locking around LOGOFF and CLOSE handlers.

Typical attack path

1. Establish an SMB session to a target running ksmbd
2. Send a sequence of SMB2_LOGOFF and SMB2_CLOSE commands with crafted timing or concurrency
3. Trigger the race condition to achieve use-after-free or object corruption
4. Execute arbitrary code within the kernel address space

How to detect it

Review kernel and SMB audit logs for anomalous sequences of LOGOFF and CLOSE operations; inspect for unexpected ksmbd crashes or kernel oops messages that may indicate exploitation attempts.

What your security team should do

• Apply the referenced kernel commit on all systems running ksmbd
• Disable ksmbd module if in-kernel SMB serving is unnecessary
• Monitor EPSS and KEV updates for any future increase in exploit activity