CVE-2022-47938

What it actually does

This vulnerability affects ksmbd, the in-kernel SMB server in Linux kernel versions 5.15 through 5.19 before 5.19.2. A malformed SMB2 TREE_CONNECT request can trigger an out-of-bounds read in fs/ksmbd/smb2misc.c, causing a kernel OOPS. The practical technical impact is denial of service: an authenticated network user with access to the SMB service can crash the ksmbd worker path and may destabilize the host depending on kernel panic/OOPS handling. The issue is not described as enabling code execution or data modification.

Why it matters to the business

Systems using Linux ksmbd for SMB file sharing may be disrupted by a low-complexity network attack from an authenticated SMB user. Successful exploitation can interrupt file share availability, affect dependent applications and users, and potentially require service or host recovery. Although it is not in CISA KEV and is not known to be ransomware-associated, the EPSS score is elevated, so internet-exposed or broadly accessible SMB services should be prioritized for remediation.

How an attack unfolds

An attacker first obtains valid credentials or otherwise gains the ability to authenticate to an SMB service backed by Linux ksmbd. The attacker connects to the SMB service over the network, performs normal SMB negotiation and session setup, then sends a specially crafted SMB2 TREE_CONNECT request that exercises vulnerable parsing in ksmbd. On vulnerable kernels, the malformed request causes an out-of-bounds read in the SMB2 handling code, leading to a kernel OOPS. Depending on system configuration, this may terminate the ksmbd thread, disrupt SMB availability, or trigger broader host instability or panic behavior.

How to fix it

Upgrade affected Linux kernels to a fixed release. The vulnerability is fixed upstream by Linux commit 824d4f64c20093275f72fc8101394d75ff6a249e and in kernel versions after the affected 5.15 through 5.19 range, including 5.19.2 or later where applicable. Prefer vendor-supported kernel packages from the operating system distribution rather than manually applying upstream patches. If immediate patching is not possible, disable ksmbd, replace it with a non-vulnerable SMB implementation where operationally appropriate, restrict SMB exposure to trusted networks, block TCP/445 from untrusted sources, and limit SMB accounts to the minimum users requiring access.

How to confirm the fix worked

Confirm the running kernel is not in the vulnerable range or includes the upstream fix. Validate with commands such as `uname -r`, distribution package changelogs, and vendor security advisories. Confirm whether ksmbd is enabled by checking for the ksmbd service/module, for example `lsmod | grep ksmbd`, `systemctl status ksmbd`, and active listeners on TCP/445. After remediation, restart or reboot as required so the fixed kernel is actually running. Validate exposure by scanning only authorized assets for SMB on TCP/445 and confirming untrusted networks cannot reach ksmbd-backed services.

Typical attack path

1. Identify a host exposing SMB services backed by Linux ksmbd.
2. Authenticate to the SMB service using valid or compromised credentials.
3. Complete SMB2 negotiation and session setup.
4. Send a malformed SMB2 TREE_CONNECT request crafted to trigger the vulnerable ksmbd parsing path.
5. Cause a kernel OOPS and disrupt SMB service availability or host stability.

How to detect it

To determine whether exploitation may have already occurred, review kernel logs, system journals, crash dumps, and SMB authentication/session logs for ksmbd crashes or OOPS events around SMB2 TREE_CONNECT activity. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, systemd unit logs for ksmbd, kernel crash dump facilities such as kdump/vmcore, and network/security telemetry for TCP/445 sessions. Look for authenticated SMB sessions followed immediately by kernel OOPS, ksmbd worker termination, service restart, host reboot, or panic. Correlate source IP addresses and usernames from SMB authentication logs with the timestamp of kernel faults. Because public reporting does not provide a unique exploit payload signature, prioritize behavioral indicators: repeated SMB connection attempts, repeated TREE_CONNECT operations, ksmbd OOPS stack traces, and unexpected denial-of-service events on ksmbd-enabled hosts.

• ksmbd
• SMB2_TREE_CONNECT
• TREE_CONNECT
• smb2_tree_connect
• fs/ksmbd/smb2misc.c
• Oops
• kernel Oops
• BUG: kernel
• general protection fault
• unable to handle kernel paging request
• ksmbd:
• ksmbd_conn_handler_loop
• ksmbd_server
• TCP/445
• microsoft-ds

What your security team should do

• Inventory Linux systems exposing SMB services and determine whether they use ksmbd rather than user-space Samba.
• Prioritize patching ksmbd-enabled systems running Linux kernel 5.15 through 5.19 before 5.19.2, especially systems reachable from untrusted networks or large internal user populations.
• Upgrade to a vendor-fixed kernel or a kernel containing upstream commit 824d4f64c20093275f72fc8101394d75ff6a249e, then reboot to activate the fixed kernel.
• Temporarily disable ksmbd or restrict TCP/445 access to trusted management and user networks if immediate patching is not possible.
• Review SMB authentication logs and kernel logs for unexplained ksmbd crashes, kernel OOPS messages, or repeated TREE_CONNECT activity before and after remediation.
• Ensure SMB accounts follow least privilege and remove unnecessary authenticated access, since exploitation requires SMB authentication.
• Add monitoring for ksmbd kernel OOPS patterns and service restarts to detect attempted denial-of-service activity.