UBUNTU-CVE-2026-74589: Use After Free
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix skredir use-after-free in send verdict skpsockmsgverdict() takes a socket reference for psock->skredir. tcpbpfsendverdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcpbpfsendmsgredir(). When applybytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 skredir = psock->skredir applybytes remains nonzero releasesock(sk) locksock(sk) applybytes reaches zero psock->skredir = NULL releasesock(sk) tcpbpfsendmsgredir(skredir) sockput(skredir) tcpbpfsendmsgredir(skredir) The final sockput() can free skredir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcpbpfsendmsgredir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcpbpfsendmsgredir+0xf39/0x1020 tcpbpfsendmsg+0x977/0x1a50 syssendto+0x32c/0x3a0 x64syssendto+0xdb/0x1b0 Allocated by task 85: skprotalloc+0x56/0x210 skclone+0x6f/0x14b0 inetcskclonelock+0x24/0x740 tcpcreateopenreqchild+0x25/0x2710 tcpv4synrecvsock+0x10a/0xe00 Freed by task 0: kasanslabfree+0x43/0x70 slabfreeafterrcudebug+0xa6/0x1e0 rcucore+0x50a/0x1850 Last potentially related work creation: skdestruct+0x3da/0x540 skpsockdestroy+0x81e/0xab0 processonework+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->skredir, and drop it after tcpbpfsendmsgredir() returns. This keeps each unlocked use independent of cached-verdict ownership.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1117.124~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1123.132~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1122.131~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1118.128~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-198.208~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1112.118~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-195.205~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-198.208 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1122.131 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1113.119 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1100.108 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1112.118 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1109.114 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-195.205 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1112.113 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-xilinx-zynqmpto a version that resolves this vulnerability.Fixed in 5.15.0-1080.84 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1101.103 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1109.111 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1116.125 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-198.208+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128+fips1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch bpf, sockmap: Fix sk_redir use-after-free in send verdict - Operational
In sk_psock_msg_verdict(), take a temporary reference to psock->sk_redir while the source socket lock protects it, and drop that reference after tcp_bpf_sendmsg_redir() returns.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected Ubuntu kernel packages listed are linux, linux-azure, linux-gcp, linux-aws-fips, linux-azure-fips, linux-fips, linux-gcp-fips, and linux-realtime. Exposure requires use of the kernel BPF sockmap send-verdict path.
What conditions are needed to trigger the use-after-free?
The race requires a cached send verdict to remain active because apply_bytes is nonzero, while concurrent sendmsg activity occurs on the same source socket. One thread can retain an unreferenced local sk_redir pointer after dropping the source socket lock, while another consumes the remaining apply_bytes and releases the cached socket reference.
How might an affected system manifest the problem?
KASAN can report a slab use-after-free in tcp_bpf_sendmsg_redir. The reported call path includes tcp_bpf_sendmsg_redir, tcp_bpf_sendmsg, and the sendto system-call path.