[BUG] Linux Kernel ksmbd Multiple Memory Leaks in Session Handling
From: ven0mfuzzer
Date: Thu Apr 02 2026 - 09:22:42 EST
Linux Kernel ksmbd Multiple Memory Leaks in Session Handling
1. Vulnerability Title
Linux Kernel ksmbd Server Multiple Kernel Memory Leak Vulnerability in Session Setup/Teardown
2. High-Level Overview
Seven distinct kernel memory leaks exist in the ksmbd (in-kernel SMB server) session handling paths. During SMB session setup and teardown, multiple kernel objects — including socket inodes (1344 bytes), LSM security blobs (120 and 32 bytes), TCP connection structures (3264 bytes), ksmbd connection contexts (64 and 16 bytes), and network skb buffers (240 bytes) — are allocated but never freed. These leaks accumulate over time with repeated session establishment, allowing a remote attacker to exhaust kernel memory by repeatedly connecting and disconnecting SMB sessions. This constitutes a denial-of-service vulnerability.
This vulnerability was discovered using ven0mfuzzer, our custom-designed MITM-based network filesystem fuzzer developed by our team. Following the common syzkaller practice, we submit the kernel crash trace as the primary reproduction artifact.
3. Affected Product and Version Information
Product: Linux Kernel (upstream mainline)
Affected Component: `fs/smb/server/` — ksmbd session setup/teardown, connection handling
Supporting Components:
- `fs/smb/server/transport_tcp.c` — `ksmbd_kthread_fn()`, `ksmbd_tcp_readv()`
- `fs/smb/server/connection.c` — connection context allocation
- `net/socket.c` — `sock_alloc_inode()`, `kernel_accept()`
- `net/ipv4/tcp_minisocks.c` — `tcp_create_openreq_child()`
Tested Versions (confirmed vulnerable)
- Linux kernel 6.19.0 (mainline, commit `44331bd6a610`, gcc 11.4.0, built 2026-02-13)
- Linux kernel 6.12.74 (LTS, used in Google kernelCTF COS target)
Affected Version Range
All kernels with ksmbd support (approximately 5.15 through 6.19) are believed affected.
Affected Distributions and Products
| Vendor / Product | Notes |
| --- | --- |
| Red Hat Enterprise Linux (RHEL 9.x) | Ships kernels >= 5.14 with ksmbd module |
| Ubuntu (22.04 LTS, 24.04 LTS) | HWE kernels 6.x include ksmbd |
| SUSE Linux Enterprise Server (SLES 15 SP5+) | Kernel 6.x based |
| Debian (Bookworm, Trixie) | Kernels 6.1+ |
| Fedora (39+) | Kernels 6.5+ |
| Amazon Linux 2023 | Kernel 6.1 LTS based |
| Google ChromeOS / COS | kernelCTF target, confirmed vulnerable on 6.12.74 |
4. Root Cause Analysis
4.a. Detailed Description
The kmemleak detector identified 7 unreferenced kernel objects allocated during ksmbd session handling that are never freed. These leaks occur across multiple subsystems involved in SMB connection management:
1. Socket inode (1344 bytes): Allocated by `sock_alloc_inode()` during `kernel_accept()` in `ksmbd_kthread_fn()`. The accepted socket's inode is not properly released when the connection is torn down.
2. LSM security blob (120 bytes): Allocated by `security_inode_alloc()` during inode initialization for the socket. Leaked because the parent inode is leaked.
3. TCP connection structure (3264 bytes): Allocated by `sk_prot_alloc()` during `tcp_create_openreq_child()` when accepting a new TCP connection. The TCP socket is not properly closed on session teardown.
4. LSM security blob for socket (32 bytes): Allocated by `security_sk_alloc()` for the cloned TCP socket. Leaked with the parent TCP structure.
5. ksmbd connection context (64 bytes): Allocated by `ksmbd_kthread_fn()` for per-connection state. Not freed when the connection handler exits abnormally.
6. ksmbd TCP read buffer (16 bytes): Allocated by `ksmbd_tcp_readv()` for receiving SMB messages. Not freed when read is interrupted.
7. SKB buffer (240 bytes): Allocated by `build_skb()` in the virtio-net receive path for incoming SMB packets. Orphaned when the associated socket is leaked.
4.b. Code Flow
---
ksmbd_kthread_fn() [fs/smb/server/transport_tcp.c]
→ kernel_accept() ← allocates socket inode (1344B) + security blob (120B)
→ sock_alloc() → alloc_inode()
→ security_inode_alloc()
TCP SYN_RECV → ESTABLISHED:
→ tcp_create_openreq_child() ← allocates TCP sock (3264B) + security blob (32B)
→ sk_prot_alloc() → sk_clone()
→ security_sk_alloc()
ksmbd_kthread_fn() continued:
→ kmalloc (64B) ← ksmbd connection context
ksmbd_conn_handler_loop():
→ ksmbd_tcp_readv()
→ kmalloc (16B) ← TCP read buffer
[on session teardown — objects NOT freed due to missing cleanup]
---
4.c. Crash Trace
This vulnerability was discovered by ven0mfuzzer. The following kmemleak output is submitted following syzkaller's common practice of providing the raw kernel trace as the primary reproduction evidence:
---
unreferenced object 0xffff88810af3d180 (size 1344):
comm "ksmbd-eth0", pid 328, jiffies 4294901355
backtrace (crc 1a26ccb4):
kmem_cache_alloc_lru_noprof+0x3ed/0x5f0
sock_alloc_inode+0x25/0x1c0
alloc_inode+0x64/0x240
sock_alloc+0x40/0x280
sock_create_lite+0x82/0x120
kernel_accept+0x16b/0x380
ksmbd_kthread_fn+0xee/0xf30
unreferenced object 0xffff888107243bd0 (size 120):
comm "ksmbd-eth0", pid 328, jiffies 4294901355
backtrace (crc 6bd3e180):
kmem_cache_alloc_noprof+0x3ed/0x5f0
security_inode_alloc+0x3b/0x140
inode_init_always_gfp+0xbf9/0xf20
alloc_inode+0x86/0x240
sock_alloc+0x40/0x280
sock_create_lite+0x82/0x120
kernel_accept+0x16b/0x380
ksmbd_kthread_fn+0xee/0xf30
unreferenced object 0xffff88810fbfa980 (size 3264):
comm "softirq", pid 0, jiffies 4294902189
backtrace (crc c2de1a0c):
kmem_cache_alloc_noprof+0x3ed/0x5f0
sk_prot_alloc+0x60/0x2a0
sk_clone+0x79/0x14f0
inet_csk_clone_lock+0x2f/0x760
tcp_create_openreq_child+0x34/0x26a0
tcp_v4_syn_recv_sock+0x115/0x10e0
unreferenced object 0xffff888108c514a0 (size 32):
comm "softirq", pid 0, jiffies 4294902189
backtrace (crc ea16adaf):
__kmalloc_noprof+0x4eb/0x760
lsm_blob_alloc+0x68/0x90
security_sk_alloc+0x2f/0xd0
sk_prot_alloc+0xfb/0x2a0
sk_clone+0x79/0x14f0
unreferenced object 0xffff88810fd0b540 (size 64):
comm "ksmbd-eth0", pid 328, jiffies 4294902189
backtrace (crc f2da5eae):
__kmalloc_cache_noprof+0x411/0x610
ksmbd_kthread_fn+0x288/0xf30
unreferenced object 0xffff8881063426f0 (size 16):
comm "ksmbd:::ffff:10", pid 434, jiffies 4294902190
backtrace (crc 9e6ee6c8):
__kmalloc_cache_noprof+0x411/0x610
ksmbd_tcp_readv.constprop.0+0x16d/0x700
ksmbd_tcp_read+0x88/0xc0
ksmbd_conn_handler_loop+0x5dd/0xfd0
unreferenced object 0xffff88810fa94200 (size 240):
comm "softirq", pid 0, jiffies 4294902419
backtrace (crc 4367e44b):
kmem_cache_alloc_noprof+0x3ed/0x5f0
build_skb+0x46/0x370
page_to_skb+0x5df/0xb30
receive_buf+0xa3e/0x4940
virtnet_poll+0xfb6/0x1750
---
Total leaked per session: approximately 5,080 bytes (1344 + 120 + 3264 + 32 + 64 + 16 + 240). An attacker establishing and tearing down sessions repeatedly can exhaust kernel memory.
4.d. Suggested Fix
The ksmbd session teardown path (`ksmbd_sessions_deregister` / `ksmbd_conn_handler_loop` exit) must properly release all allocated resources:
1. Close the accepted socket via `sock_release()` to free the socket inode and associated LSM blobs
2. Properly tear down the cloned TCP socket
3. Free the ksmbd connection context and read buffers on all exit paths, including error/abort paths
5. Discovery Method and Reproduction
5.a. Discovery
This vulnerability was discovered using ven0mfuzzer, a custom-designed MITM-based network filesystem fuzzer developed by our team. The fuzzer operates by positioning an AF_PACKET/TCP transparent proxy between a Linux kernel filesystem client (VM-A) and its server (VM-B), then mutating network protocol messages in-flight.
Following the common syzkaller practice, we submit the kernel kmemleak output as the primary reproduction artifact. The output above was captured with CONFIG_DEBUG_KMEMLEAK enabled on kernel 6.19.0.
5.b. Reproduction Setup
---
VM-A (CIFS client) ──SMB2──► Host:44446 (MITM proxy) ──TCP──► Host:44445 ──hostfwd──► VM-B:445 (ksmbd)
---
Trigger condition: Repeated SMB session establishment and teardown, especially when the MITM proxy disrupts the session setup handshake, forcing abnormal teardown paths.
---
Reported-by: ven0mfuzzer <ven0mkernelfuzzer@xxxxxxxxx>
Link: https://github.com/KernelStackFuzz/KernelStackFuzz