Linux ksmbd CVE-2026-98162

Requires the Linux in-kernel SMB server (ksmbd / CONFIG_SMB_SERVER) to be built and running with at least one share exported - a non-default configuration on the vast majority of Linux systems. Exploitation requires an authenticated SMB session (PR:L) able to reach smb2_tree_connect(). The leak is further gated on the ksmbd_iov_pin_rsp() response-pinning step failing (a NOMEM/allocation-failure condition), which is not directly attacker-controlled and limits reliable triggering; impact is limited to slow kernel memory exhaustion rather than compromise.

This is a genuinely moderate, low-priority issue rather than a false high. All signals align downward: the input CVSS is 5.5 (MEDIUM), EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, and no public exploit was identified. The CWE-401 memory leak maps to the CVSS impact profile (C:N/I:N/A:H) - the only consequence is gradual kernel memory exhaustion (a denial-of-service), not code execution or data exposure. One signal conflict warrants attention: the supplied CVSS uses AV:L (local), yet ksmbd is Linux's in-kernel SMB3 server and smb2_tree_connect() is reached over the network after an authenticated session is established, which argues for a network vector - verify the attack vector with the kernel CNA, as it materially affects reach. The PR:L metric is consistent with the fact that tree-connect only occurs after SMB session setup, so some authentication is required. The leak path also depends on ksmbd_iov_pin_rsp() failing (a memory-allocation/NOMEM condition), which is not directly attacker-controlled, further lowering practical exploitability. Net: a defensible medium that should be patched in the normal cycle, not an emergency.

An attacker with valid credentials to an exposed ksmbd share repeatedly opens SMB2 tree connections; each time the server fails to pin the response buffer (under memory pressure), the tree-connection object, its counter, and share reference are leaked rather than disconnected. Sustained over time this slowly exhausts kernel memory, degrading or crashing the host. No public exploit code was identified at time of analysis, and the leak only triggers on the allocation-failure path, making reliable exploitation difficult.