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

tcp/dccp: Don't use timerpending() in reqskqueueunlink().

Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler().

""" We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """

The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window.

Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending.

If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.

The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default.

The scenario would be

1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed

2. reqsk timer is executed and scheduled again

3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets

4. sk is close()d

5. reqsk timer is executed again, and BPF touches req->sk

Let's not use timerpending() by passing the caller context to inetcskreqskqueuedrop().

Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]

[0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0

Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb

kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb

freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb

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

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

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

smb: client: Fix use-after-free of network namespace.

Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0]

The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying.

The root cause is wrong reference counting for network namespace.

CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.

The repro steps are roughly:

1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS

We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIGNETNSREFCNTTRACKER is enabled.

When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.

Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcpwritetimerhandler().").

Note that we need to move putnet() from cifsputtcpsession() to cleandemultiplexinfo(); otherwise, sockcreate() still could touch a freed netns while cifsd tries to reconnect from cifsdemultiplexthread().

Also, maybegetnet() cannot be put just before sockcreate() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.

[0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: clsbpf schingress nlsutf8 cifs cifsarc4 cifsmd4 dnsresolver tcpdiag inetdiag veth xtstate xtconnmark nfconntracknetlink xtnat xtstatistic xtMASQUERADE xtmark xtaddrtype iptREJECT nfrejectipv4 nftchainnat nfnat xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment nftcompat nftables nfnetlink overlay nlsascii nlscp437 sunrpc vfat fat aesceblk aescecipher ghashce sm4cecipher sm4 sm3ce sm3 sha3ce sha512ce sha512arm64 sha1ce ena button schfqcodel loop fuse configfs dmisysfs sha2ce sha256arm64 dmmirror dmregionhash dmlog dmmod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fibruleslookup+0x44/0x238 lr : fiblookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fibruleslookup+0x44/0x238 fiblookup+0x64/0xbc iprouteoutputkeyhashrcu+0x2c4/0x398 iprouteoutputkeyhash+0x60/0x8c tcpv4connect+0x290/0x488 inetstreamconnect+0x108/0x3d0 inetstreamconnect+0x50/0x78 kernelconnect+0x6c/0xac genericipconne ---truncated---

A flaw was found in the Linux kernel. A heap based buffer overflow in mwifiexuapparsetailies function in drivers/net/wireless/marvell/mwifiex/ie.c might lead to memory corruption and possibly other consequences.

Last updated 4 July 2026

Last updated 24 July 2024

A flaw was found in the Linux kernels implementation of seqfile where an local attacker could create a situation in which an attacker could manipulate memory in which the function pointer to put() could be used for malicious purposes. This could lead to memory corruption and possible privledged escalation.

There are no exploits available for this flaw at this time.

Upstream patch:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=77da160530dd1dc94f6ae15a981f24e5f0021e84

udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSGPEEK flag.

Use-after-free vulnerability in the ffsusercopyworker function in drivers/usb/gadget/function/ffs.c in the Linux kernel before 4.5.3 allows local users to gain privileges by accessing an I/O data structure after a certain callback call.

The ext4journalstop function in fs/ext4/ext4jbd2.c in the Linux kernel before 4.3.3 allows local users to gain privileges or cause a denial of service (use-after-free) by leveraging improper access to a certain error field.

Race condition in the ionioctl function in drivers/staging/android/ion/ion.c in the Linux kernel before 4.6 allows local users to gain privileges or cause a denial of service (use-after-free) by calling IONIOCFREE on two CPUs at the same time.