CVE-2026-68083

This CVE (9.1 critical) exposes a fundamental asymmetry in ksmbd's path resolution architecture that you need to understand at the API level, not just patch at the symptom level. The vulnerability: ksmbd uses LOOKUP_BENEATH to constrain path resolution within share boundaries for SMB2 lookup/open operations. But ksmbd_vfs_kern_path_create(), which handles create/mkdir/hardlink operations, builds absolute paths and resolves them from AT_FDCWD with no containment guarantee. These two code paths handle the same logical operation — file access via SMB — but make opposite security assumptions. The lookup path assumes adversarial input and guards against traversal. The create path assumes a trusted caller and doesn't. The race condition in the CVE description is the exploitation mechanism, not the root cause. The create path doesn't "sometimes" escape the share — it structurally cannot contain resolution because it resolves from AT_FDCWD unconditionally. An attacker needs the race to trigger the create branch at the right moment, but the vulnerability exists whenever ksmbd_vfs_kern_path_create() processes a path component containing '..'. The patch removes convert_to_unix_name() entirely, declaring it dead code. This is significant: an entire abstraction was wrong from its introduction and survived with zero callers — a landmine for any future maintainer who might have resurrected it or written something adjacent inheriting its broken assumptions. Practical implications for defenders: First, this affects ksmbd deployments in storage appliances and embedded NAS systems — not general-purpose servers. The CVSS is 9.1, but the EPSS is low because ksmbd's footprint is concentrated in infrastructure roles where compromise is catastrophic but exploitation requires authenticated SMB access you already have via the share. Second, the patch fixes this instance but doesn't close the architectural gap. Unless ksmbd introduces a unified contained path resolution primitive that both lookup and create paths inherit, this pattern will recur — we've seen the same containment-violating anti-pattern in cifs.ko, overlayfs, and container runtimes. Your priority: verify which ksmbd version you're running and patch immediately if below the fixed version. If you're on an appliance with slow patch cycles, treat this as critical because the attack surface (authenticated SMB share access) is already in the threat model's reach. Audit your SMB share configuration for any path traversal patterns that could trigger the create code path, and monitor for any new filesystem objects appearing outside intended share roots.

Reviewed through automated stages and approved by a human before publication.