Linux ksmbd CVE-2026-90176

Requires the target to run the in-kernel ksmbd SMB server (CONFIG_SMB_SERVER) with an exported share, and the attacker to hold a valid authenticated SMB session (PR:L). Exploitation only matters when byte-range locking is in use - a conflicting lock covering the targeted byte must already exist (typically set by another client). Impact is limited to single-byte-range read, write, copychunk, and one-byte truncate operations; multi-byte ranges were always checked correctly. This is a non-default, application-behavior-dependent condition (clients must actually rely on mandatory byte-range locks), which sharply limits real-world exposure despite the network attack vector.

Vendor CVSS is 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), which overstates real-world impact. This is a logic off-by-one in ksmbd's check_lock_range(): because ranges are inclusive (end = start + length - 1), a single-byte range (start == end) was wrongly treated as empty and skipped mandatory byte-range lock enforcement. The real consequence is that a conflicting lock covering exactly one byte is not honored for one-byte reads, writes, copychunk, and one-byte truncate operations - an SMB mandatory-lock bypass, not a memory-safety flaw. AC:L is defensible (deterministic logic bug, no race), but C:H/I:H is optimistic: the bypass is scoped to single-byte ranges and to files where another client holds a byte-range lock, so C:L/I:L is more honest, yielding ~5.4. No EPSS, no CISA KEV entry, and no public exploit - 'no public exploit identified at time of analysis'. AV:N is correct (SMB is network-facing) but exploitation requires an authenticated SMB session (PR:L) and a non-default scenario where clients rely on byte-range locking. Net: a real correctness/authorization fix worth patching on ksmbd fleets, but far below the 8.1 headline for most environments.

On a Linux host running the in-kernel ksmbd SMB server, an authenticated SMB user opens a shared file that another client has protected with a byte-range lock. The attacker issues a one-byte read, write, copychunk, or truncate operation targeting the locked byte; because the start == end shortcut skipped the lock check, the operation is permitted despite the conflicting lock, bypassing SMB mandatory-lock semantics. No public exploit code is identified at time of analysis.