CVE ID : CVE-2023-53685<\/p>\n
Published : Oct. 7, 2025, 4:15 p.m. | 19\u00a0minutes ago<\/p>\n
Description : In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
tun: Fix memory leak for detached NAPI queue.<\/p>\n
syzkaller reported [0] memory leaks of sk and skb related to the TUN
\ndevice with no repro, but we can reproduce it easily with:<\/p>\n
struct ifreq ifr = {}
\n int fd_tun, fd_tmp;
\n char buf[4] = {};<\/p>\n
fd_tun = openat(AT_FDCWD, “\/dev\/net\/tun”, O_WRONLY, 0);
\n ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;
\n ioctl(fd_tun, TUNSETIFF, &ifr);<\/p>\n
ifr.ifr_flags = IFF_DETACH_QUEUE;
\n ioctl(fd_tun, TUNSETQUEUE, &ifr);<\/p>\n
fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);
\n ifr.ifr_flags = IFF_UP;
\n ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);<\/p>\n
write(fd_tun, buf, sizeof(buf));
\n close(fd_tun);<\/p>\n
If we enable NAPI and multi-queue on a TUN device, we can put skb into
\ntfile->sk.sk_write_queue after the queue is detached. We should prevent
\nit by checking tfile->detached before queuing skb.<\/p>\n
Note this must be done under tfile->sk.sk_write_queue.lock because write()
\nand ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would
\nbe a small race window:<\/p>\n
write() ioctl(IFF_DETACH_QUEUE)
\n `- tun_get_user `- __tun_detach
\n |- if (tfile->detached) |- tun_disable_queue
\n | `-> false | `- tfile->detached = tun
\n | `- tun_queue_purge
\n |- spin_lock_bh(&queue->lock)
\n `- __skb_queue_tail(queue, skb)<\/p>\n
Another solution is to call tun_queue_purge() when closing and
\nreattaching the detached queue, but it could paper over another
\nproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.<\/p>\n[0]:
\nunreferenced object 0xffff88801edbc800 (size 2048):
\n comm “syz-executor.1”, pid 33269, jiffies 4295743834 (age 18.756s)
\n hex dump (first 32 bytes):
\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
\n 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 …@…………
\n backtrace:
\n [] __do_kmalloc_node mm\/slab_common.c:965 [inline]\n [] __kmalloc+0x4a\/0x130 mm\/slab_common.c:979
\n [] kmalloc include\/linux\/slab.h:563 [inline]\n [] sk_prot_alloc+0xef\/0x1b0 net\/core\/sock.c:2035
\n [] sk_alloc+0x36\/0x2f0 net\/core\/sock.c:2088
\n [] tun_chr_open+0x3d\/0x190 drivers\/net\/tun.c:3438
\n [] misc_open+0x1a6\/0x1f0 drivers\/char\/misc.c:165
\n [] chrdev_open+0x111\/0x300 fs\/char_dev.c:414
\n [] do_dentry_open+0x2f9\/0x750 fs\/open.c:920
\n [] do_open fs\/namei.c:3636 [inline]\n [] path_openat+0x143f\/0x1a30 fs\/namei.c:3791
\n [] do_filp_open+0xce\/0x1c0 fs\/namei.c:3818
\n [] do_sys_openat2+0xf0\/0x260 fs\/open.c:1356
\n [] do_sys_open fs\/open.c:1372 [inline]\n [] __do_sys_openat fs\/open.c:1388 [inline]\n [] __se_sys_openat fs\/open.c:1383 [inline]\n [] __x64_sys_openat+0x83\/0xf0 fs\/open.c:1383
\n [] do_syscall_x64 arch\/x86\/entry\/common.c:50 [inline]\n [] do_syscall_64+0x3c\/0x90 arch\/x86\/entry\/common.c:80
\n [] entry_SYSCALL_64_after_hwframe+0x72\/0xdc<\/p>\n
unreferenced object 0xffff88802f671700 (size 240):
\n comm “syz-executor.1”, pid 33269, jiffies 4295743854 (age 18.736s)
\n hex dump (first 32 bytes):
\n 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h…….h…….
\n 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{\/…………
\n backtrace:
\n [] __alloc_skb+0x223\/0x250 net\/core\/skbuff.c:644
\n [] alloc_skb include\/linux\/skbuff.h:1288 [inline]\n [] alloc_skb_with_frags+0x6f\/0x350 net\/core\/skbuff.c:6378
\n [] sock_alloc_send_pskb+0x3ac\/0x3e0 net\/core\/sock.c:2729
\n [] tun_alloc_skb drivers\/net\/tun.c:1529 [inline]\n [
\nSeverity: 0.0 | NA<\/p>\n
Visit the link for more details, such as CVSS details, affected products, timeline, and more…\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"
CVE ID : CVE-2023-53685 Published : Oct. 7, 2025, 4:15 p.m. | 19\u00a0minutes ago Description : 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 …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-71116","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/71116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=71116"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/71116\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=71116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=71116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=71116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}