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