CVE-2023-52479

What it actually does

Use-after-free in ksmbd SMB2 oplock break acknowledgment handler where opinfo reference is released after the object has already been dereferenced, enabling memory corruption.

Why it matters to the business

Systems exposing SMB file shares via the Linux kernel may experience crashes, denial of service, or potential code execution, disrupting file services and requiring urgent kernel updates on servers and appliances.

How an attack unfolds

An attacker establishes an SMB2 session, triggers oplock state changes, and sends a crafted oplock break acknowledgment packet that causes the kernel to use a freed opinfo structure.

How to fix it

Update the Linux kernel to include commit 694e13732e830cbbfedb562e57f28644927c33fd or later; rebuild and reboot affected systems; disable ksmbd if SMB server functionality is not required.

How to confirm the fix worked

Verify the running kernel contains commit 694e13732e830cbbfedb562e57f28644927c33fd via git log or kernel version; confirm ksmbd module is updated or unloaded; test SMB2 oplock scenarios for stability.

Typical attack path

1. Establish authenticated SMB2 connection to ksmbd
2. Request file open that grants oplock
3. Send malicious smb20_oplock_break_ack packet
4. Trigger use of already-freed opinfo object
5. Achieve memory corruption or kernel panic

How to detect it

Review kernel logs for oops, warnings, or slab corruption messages mentioning ksmbd or smb2; inspect SMB2 traffic for anomalous oplock break sequences; correlate with process crashes on file servers.

What your security team should do

• Apply the referenced kernel commit immediately on all systems running ksmbd
• Prioritize patching internet-facing or multi-user file servers first
• Monitor for kernel oops or crashes related to ksmbd after patching
• Consider disabling ksmbd in favor of userspace Samba where feasible