CVE-2023-53489
NoneCVSS
—
EPSS
0.2%
Published
Oct 1, 2025
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network code can slowly leak memory when certain advanced socket features are used together, eventually using up resources and slowing or crashing the system.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Memory leaks of sockets and zerocopy skbs occur due to a circular reference between struct ubuf_info_msgzc and socket refcount when SO_TIMESTAMPING_TX_SOFTWARE and SO_ZEROCOPY are combined; the error queue is not purged correctly on close, preventing sock_put and skb release.
Why it matters to the business
Systems performing network operations with TX timestamping and zerocopy sockets experience gradual memory exhaustion that can degrade performance or cause denial of service; widespread use of Linux kernel networking makes this relevant across servers and containers.
How an attack unfolds
An attacker creates an AF_INET SOCK_DGRAM socket, enables SO_TIMESTAMPING_TX_SOFTWARE and SO_ZEROCOPY via setsockopt, performs a MSG_ZEROCOPY sendto, then closes the socket; the resulting skb clone in the error queue retains an unreleased reference, leaking both the socket and skb objects.
How to fix it
Apply the upstream fix in commit 281072fb2a7294cde7acbf5375b879f40a8001b7 or later stable kernel releases that include the call to skb_orphan_frags_rx in __skb_tstamp_tx for zerocopy clones; rebuild and reboot affected systems.
How to confirm the fix worked
Confirm the fix is present by checking kernel git history for commit 281072fb2a7294cde7acbf5375b879f40a8001b7; reproduce the original syzkaller sequence and monitor for leaks using kmemleak or slabinfo before and after the update.
Typical attack path
- Create UDP or TCP socket with AF_INET
- Enable SO_TIMESTAMPING_TX_SOFTWARE and SO_ZEROCOPY via setsockopt
- Send zero-length message with MSG_ZEROCOPY flag
- Close the socket without draining the error queue
- Repeat to accumulate leaked kernel memory objects
How to detect it
Search kernel logs and audit trails for repeated socket creation patterns matching the syzkaller reproducer; use memory leak detectors such as kmemleak to identify unreferenced sk and skb objects after socket close operations.
What your security team should do
- Prioritize patching kernel images that expose networking to untrusted workloads
- Audit for use of SO_ZEROCOPY combined with TX timestamping in applications
- Monitor memory usage trends on systems handling high volumes of timestamped zerocopy traffic
- Test patched kernels in staging before broad deployment
The record
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 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>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+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>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>] ---truncated---
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 4.14.0 | 4.14.315 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-64kb | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-default-base | 0 | 5.14.21-150500.55.124.1.150500.6.59.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-docs | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-obs-build | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-source | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS | kernel-syms | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-64kb | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-default-base | 0 | 5.14.21-150500.55.124.1.150500.6.59.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-docs | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-obs-build | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-source | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS | kernel-syms | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Live Patching 15 SP5 | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Live Patching 15 SP5 | kernel-livepatch-SLE15-SP5_Update_31 | 0 | 1-150500.11.3.1 |
| SUSE:Linux Enterprise Micro 5.5 | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Micro 5.5 | kernel-default-base | 0 | 5.14.21-150500.55.124.1.150500.6.59.1 |
| SUSE:Linux Enterprise Micro 5.5 | kernel-rt | 0 | 5.14.21-150500.13.109.1 |
| SUSE:Linux Enterprise Micro 5.5 | kernel-source | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Micro 5.5 | kernel-source-rt | 0 | 5.14.21-150500.13.109.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-64kb | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-default-base | 0 | 5.14.21-150500.55.124.1.150500.6.59.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-docs | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-obs-build | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-source | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-syms | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server 15 SP5-LTSS | kernel-zfcpdump | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-default | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-default-base | 0 | 5.14.21-150500.55.124.1.150500.6.59.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-docs | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-obs-build | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-source | 0 | 5.14.21-150500.55.124.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP5 | kernel-syms | 0 | 5.14.21-150500.55.124.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel