CVE-2023-53685

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Oct 7, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of certain network tunnel devices can slowly leak memory when specific advanced features are used, which over time may slow down or crash the system.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Memory Corruption
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Memory leak of socket (sk) and socket buffer (skb) objects in the TUN driver when NAPI and multi-queue are enabled on a device and a queue is subsequently detached via IFF_DETACH_QUEUE, allowing skbs to be enqueued after detachment without proper purging.

Why it matters to the business

Local processes can trigger gradual memory exhaustion on Linux systems that use TUN/TAP interfaces with NAPI and multi-queue features, potentially leading to degraded performance or denial of service; the issue has been present for over a year with a low but slowly rising exploitation probability.

How an attack unfolds

An attacker with local access opens /dev/net/tun, configures a device with IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE, detaches the queue, performs operations that enqueue skbs (such as packet writes), and closes the device, leaving allocated objects unreferenced due to a missing detached-state check under the queue lock.

How to fix it

Apply the upstream fix from commit 9cae243b9ae25adfe468cd47ceca591f6725b79c or upgrade to a Linux kernel release that contains this commit; rebuild and reboot with the patched kernel on all affected systems.

How to confirm the fix worked

Verify the running kernel source contains commit 9cae243b9ae25adfe468cd47ceca591f6725b79c or later; confirm absence of the vulnerable code path that queues skbs without checking tfile->detached under the write-queue lock.

Typical attack path

Open /dev/net/tun and issue TUNSETIFF with NAPI and multi-queue flags
Issue TUNSETQUEUE with IFF_DETACH_QUEUE to detach the queue
Perform write operations that allocate and queue skbs via tun_get_user
Close the file descriptor without the detached queue being purged
Repeat to accumulate leaked sk and skb objects

How to detect it

Review kernel memory leak reports via kmemleak or slabinfo for sk_prot_alloc and alloc_skb patterns tied to tun_chr_open or tun_get_user; inspect system logs for repeated TUN device open/ioctl/close sequences from untrusted processes.

What your security team should do

Prioritize kernel upgrades on systems exposing TUN devices to untrusted local users
Monitor memory usage of processes interacting with /dev/net/tun for anomalous growth
Restrict local access to TUN device creation where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: tun: Fix memory leak for detached NAPI queue. syzkaller reported [0] memory leaks of sk and skb related to the TUN device with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun); If we enable NAPI and multi-queue on a TUN device, we can put skb into tfile->sk.sk_write_queue after the queue is detached. We should prevent it by checking tfile->detached before queuing skb. Note this must be done under tfile->sk.sk_write_queue.lock because write() and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would be a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb) Another solution is to call tun_queue_purge() when closing and reattaching the detached queue, but it could paper over another problems. Also, we do the same kind of test for IFF_NAPI_FRAGS. [0]: unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [< ---truncated---

Affected packages

Ecosystem	Package	Introduced	Fixed
Linux	Kernel	3.8.0	6.1.30