CVE-2023-53489

In the Linux kernel, the following vulnerability has been resolved:

tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.

syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPY skbs. We can reproduce the problem with these sequences:

sk = socket(AFINET, SOCKDGRAM, 0) sk.setsockopt(SOLSOCKET, SOTIMESTAMPING, SOFTIMESTAMPINGTXSOFTWARE) sk.setsockopt(SOLSOCKET, SOZEROCOPY, 1) sk.sendto(b'', MSGZEROCOPY, ('127.0.0.1', 53)) sk.close()

sendmsg() calls msgzerocopyalloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sockhold(). Here, struct ubufinfo_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skbtstamptx() clones it and puts the clone into the socket's error queue with the TX timestamp.

When the original skb is received locally, skbcopyubufs() calls skbunclone(), and pskbexpandhead() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubufinfo_msgzc still has a refcnt, so __msgzerocopycallback() is not called.

The last refcnt is not released unless we retrieve the TX timestamped skb by recvmsg(). Since we clear the error queue in inetsockdestruct() after the socket's refcnt reaches 0, there is a circular dependency. If we close() the socket holding such skbs, we never call sock_put() and leak the count, sk, and skb.

TCP has the same problem, and commit e0c8bccd40fc ("net: stream: purge skerrorqueue in skstreamkillqueues()") tried to fix it by calling skbqueuepurge() during close(). However, there is a small chance that skb queued in a qdisc or device could be put into the error queue after the skbqueue_purge() call.

In __skbtstamptx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skbclone() does not call skbcopyubufs() for zerocopy skb. So, we need to call skborphanfragsrx() for the cloned skb to call skbcopyubufs().

unreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] skprotalloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] skalloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inetcreate net/ipv4/afinet.c:319 [inline] [<0000000066f3c7e0>] inetcreate+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sockcreate+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sockcreate net/socket.c:1566 [inline] [<00000000b9b11231>] __syssocketcreate net/socket.c:1603 [inline] [<00000000b9b11231>] __syssocketcreate net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __dosyssocket net/socket.c:1649 [inline] [<000000004fb45142>] __sesyssocket net/socket.c:1647 [inline] [<000000004fb45142>] __x64syssocket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] dosyscall64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entrySYSCALL64afterhwframe+0x63/0xcd

BUG: memory leak unreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] _allocskb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] allocskb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sockomalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msgzerocopyalloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---