CVE-2025-68786

What it actually does

Integer underflow in ksmbd when computing size-1 for check_lock_range on a file whose i_size equals the requested lock size of zero, bypassing intended validation.

Why it matters to the business

Potential kernel instability or crashes on Linux systems running ksmbd SMB shares, which could disrupt file serving workloads; low likelihood of exploitation given stable low EPSS and absence from KEV.

How an attack unfolds

An attacker establishes an SMB session to a ksmbd server and issues a crafted lock request where the range size exactly matches the target's current i_size of zero, causing the underflow during the skipped-equal-size check that was previously performed.

How to fix it

Apply the upstream fix by updating to Linux kernel commit 52fcbb92e0d3acfd1448b2a43b6595d540da5295 or any stable tree incorporating that change; rebuild and deploy updated kernel packages.

How to confirm the fix worked

Confirm the running kernel contains commit 52fcbb92e0d3acfd1448b2a43b6595d540da5295 via git log or kernel version string; perform functional testing of SMB lock operations on zero-length files.

Typical attack path

1. Locate Linux hosts exposing ksmbd SMB shares
2. Authenticate and open a file handle via SMB
3. Issue SMB locking request with start offset equal to current i_size and length zero
4. Trigger the size-1 underflow path in check_lock_range

How to detect it

Review kernel logs for ksmbd-related oops or underflow panics; inspect SMB network traffic for lock requests where length equals the reported file size of zero.

What your security team should do

• Prioritize kernel updates on all systems using ksmbd
• Audit environments for ksmbd usage and disable the module where SMB sharing is not required
• Monitor kernel logs for oops/panic entries referencing ksmbd lock range handling