CVE-2023-53685

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:
[] __do_kmalloc_node mm/slab_common.c:965 [inline]
[] __kmalloc+0x4a/0x130 mm/slab_common.c:979
[] kmalloc include/linux/slab.h:563 [inline]
[] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035
[] sk_alloc+0x36/0x2f0 net/core/sock.c:2088
[] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438
[] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165
[] chrdev_open+0x111/0x300 fs/char_dev.c:414
[] do_dentry_open+0x2f9/0x750 fs/open.c:920
[] do_open fs/namei.c:3636 [inline]
[] path_openat+0x143f/0x1a30 fs/namei.c:3791
[] do_filp_open+0xce/0x1c0 fs/namei.c:3818
[] do_sys_openat2+0xf0/0x260 fs/open.c:1356
[] do_sys_open fs/open.c:1372 [inline]
[] __do_sys_openat fs/open.c:1388 [inline]
[] __se_sys_openat fs/open.c:1383 [inline]
[] __x64_sys_openat+0x83/0xf0 fs/open.c:1383
[] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
[] 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:
[] __alloc_skb+0x223/0x250 net/core/skbuff.c:644
[] alloc_skb include/linux/skbuff.h:1288 [inline]
[] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378
[] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729
[] tun_alloc_skb drivers/net/tun.c:1529 [inline]
[<
—truncated—