cbcvebase.
CVE-2023-53489
published 2025-10-01

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]…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.15%
4.6th percentile
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(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close() sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, sets skb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, struct ubuf_info_msgzc indirectly holds a refcnt of the socket. When the skb is sent, __skb_tstamp_tx() clones it and puts the clone into the socket's error queue with the TX timestamp. When the original skb is received locally, skb_copy_ubufs() calls skb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt. This additional count is decremented while freeing the skb, but struct ubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() 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 inet_sock_destruct() 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 sk_error_queue in sk_stream_kill_queues()") tried to fix it by calling skb_queue_purge() 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 skb_queue_purge() call. In __skb_tstamp_tx(), the cloned skb should not have a reference to the ubuf to remove the circular dependency, but skb_clone() does not call skb_copy_ubufs() for zerocopy skb. So, we need to call skb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs(). [0]: BUG: memory leak unreferenced ob

Affected

23 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.37-1 (bookworm)linux 6.1.37-1 (bookworm)
linuxlinux——
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 281072fb2a7294cde7acbf5375b879f40a8001b7281072fb2a7294cde7acbf5375b879f40a8001b7
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 1f69c086b20e27763af28145981435423f0882681f69c086b20e27763af28145981435423f088268
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 602fa8af44fd55a58f9e94eb673e8adad2c6cc46602fa8af44fd55a58f9e94eb673e8adad2c6cc46
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 230a5ed7d813fb516de81d23f09d7506753e41e9230a5ed7d813fb516de81d23f09d7506753e41e9
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a43e4197dd5f6b474a8b16f8b6a42cd45cf4f9d1a
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < cb52e7f24c1d01a536a847dff0d1d95889cc3b5ccb52e7f24c1d01a536a847dff0d1d95889cc3b5c
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 30290f210ba7426ff7592fe2eb4114b1b5bad21930290f210ba7426ff7592fe2eb4114b1b5bad219
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 426384dd4980040651536fef5feac4dcc4d7ee4e426384dd4980040651536fef5feac4dcc4d7ee4e
linuxlinux>= f214f915e7db99091f1312c48b30928c1e0c90b7 < 50749f2dd6854a41830996ad302aef2ffaf011d850749f2dd6854a41830996ad302aef2ffaf011d8
linuxlinux_kernel>= 0 < 5.10.191-15.10.191-1
linuxlinux_kernel>= 0 < 6.1.37-16.1.37-1
linuxlinux_kernel>= 0 < 6.3.7-16.3.7-1
linuxlinux_kernel>= 0 < 6.3.7-16.3.7-1
linuxlinux_kernel>= 4.14 < 4.14.3154.14.315
linuxlinux_kernel>= 4.15 < 4.19.2834.19.283
linuxlinux_kernel>= 4.20 < 5.4.2435.4.243
linuxlinux_kernel>= 5.11 < 5.15.1115.15.111
linuxlinux_kernel>= 5.16 < 6.1.286.1.28
linuxlinux_kernel>= 5.5 < 5.10.1805.10.180
linuxlinux_kernel>= 6.2 < 6.2.156.2.15
linuxlinux_kernel>= 6.3 < 6.3.26.3.2

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.