A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability.
drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release.
A flaw in the Linux Kernel found. A use-after-free vulnerability in the Linux kernel's net/sched: clsu32 component can be exploited to achieve local privilege escalation. If tcfchangeindev() fails, u32setparms() will immediately return an error after incrementing or decrementing the reference counter in tcfbindfilter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc
A use-after-free vulnerability in the Linux kernel's afunix component can be exploited to achieve local privilege escalation.
The unixstreamsendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unixstreamsendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.
We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c.
In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()
If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().
If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.
Add the tsk->exitstate check into runposixcputimers() to fix this.
This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.
futex: Clear stale exiting pointer in futexlockpi() retry path
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxyverf
A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.
In the Linux kernel, the following vulnerability has been resolved:
tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().
syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]
syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:
1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination
As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.
Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.
Let's call reqskfastopenremove() in tcpdisconnect().
[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>
fs/buffer: fix use-after-free when call bhread() helper
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconncount: Fully initialize struct nfconncounttuple in inserttree()
Since commit b36e4523d4d5 ("netfilter: nfconncount: fix garbage collection confirm race"), cpu and jiffies32 were introduced to the struct nfconncounttuple.
The commit made nfconncountadd() initialize conn->cpu and conn->jiffies32 when allocating the struct. In contrast, counttree() was not changed to initialize them.
By commit 34848d5c896e ("netfilter: nfconncount: Split insert and traversal"), counttree() was split and the relevant allocation code now resides in inserttree(). Initialize conn->cpu and conn->jiffies32 in inserttree().
BUG: KMSAN: uninit-value in findorevict net/netfilter/nfconncount.c:117 [inline] BUG: KMSAN: uninit-value in nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 findorevict net/netfilter/nfconncount.c:117 [inline] nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 counttree net/netfilter/nfconncount.c:438 [inline] nfconncountcount+0x82f/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ipv4/ipinput.c:669 netifreceiveskblistptype net/core/dev.c:5936 [inline] netifreceiveskblistcore+0x15c5/0x1670 net/core/dev.c:5983 netifreceiveskblist net/core/dev.c:6035 [inline] netifreceiveskblistinternal+0x1085/0x1700 net/core/dev.c:6126 netifreceiveskblist+0x5a/0x460 net/core/dev.c:6178 xdprecvframes net/bpf/testrun.c:280 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2e86/0x3480 net/bpf/testrun.c:390 bpfprogtestrunxdp+0xf1d/0x1ae0 net/bpf/testrun.c:1316 bpfprogtestrun+0x5e5/0xa30 kernel/bpf/syscall.c:4407 sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 dosysbpf kernel/bpf/syscall.c:5902 [inline] sesysbpf kernel/bpf/syscall.c:5900 [inline] ia32sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32syscall+0x394d/0x4180 arch/x86/include/generated/asm/syscalls32.h:358 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/common.c:387 dofastsyscall32+0x38/0x80 arch/x86/entry/common.c:412 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:450 entrySYSENTERcompatafterhwframe+0x84/0x8e
Uninit was created at: slabpostallochook mm/slub.c:4121 [inline] slaballocnode mm/slub.c:4164 [inline] kmemcacheallocnoprof+0x915/0xe10 mm/slub.c:4171 inserttree net/netfilter/nfconncount.c:372 [inline] counttree net/netfilter/nfconncount.c:450 [inline] nfconncountcount+0x1415/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ip ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: gso: fix ownership in udpgsosegment
In udpgsosegment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug:
kernel BUG at ./include/linux/skbuff.h:3312! (skborphan) RIP: 0010:iprcvcore+0x8b2/0xca0 Call Trace: iprcv+0xab/0x6e0 netifreceiveskbonecore+0x168/0x1b0 processbacklog+0x384/0x1100 napipoll.constprop.0+0xa1/0x370 netrxaction+0x925/0xe50
The above can happen following a sequence of events when using OpenVSwitch, when an OVSACTIONATTRUSERSPACE action precedes an OVSACTIONATTROUTPUT action:
1. OVSACTIONATTRUSERSPACE is handled (in doexecuteactions): the skb goes through queuegsopackets and then udpgsosegment, where its destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVSACTIONATTROUTPUT is handled (in doexecuteactions) and the same original skb is sent to its path. 4. If it later hits skborphan, we hit the bug.
Fix this by also removing the reference to the socket in udpgsosegment.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: use RCU protection in ip6defaultadvmss()
ip6defaultadvmss() needs rcu protection to make sure the net structure it reads does not disappear.
In the Linux kernel, the following vulnerability has been resolved:
ndisc: use RCU protection in ndiscallocskb()
ndiscallocskb() can be called without RTNL or RCU being held.
Add RCU protection to avoid possible UAF.
In the Linux kernel, the following vulnerability has been resolved:
ndisc: extend RCU protection in ndiscsendskb()
ndiscsendskb() can be called without RTNL or RCU held.
Acquire rcureadlock() earlier, so that we can use devnetrcu() and avoid a potential UAF.
In the Linux kernel, the following vulnerability has been resolved:
nbd: don't allow reconnect after disconnect
Following process can cause nbdconfig UAF:
1) grab nbdconfig temporarily;
2) nbdgenldisconnect() flush all recvwork() and release the initial reference:
nbdgenldisconnect nbddisconnectandput nbddisconnect flushworkqueue(nbd->recvworkq) if (testandclearbit(NBDRTHASCONFIGREF, ...)) nbdconfigput -> due to step 1), reference is still not zero
3) nbdgenlreconfigure() queue recvwork() again;
nbdgenlreconfigure config = nbdgetconfigunlocked(nbd) if (!config) -> succeed if (!testbit(NBDRTBOUND, ...)) -> succeed nbdreconnectsocket queuework(nbd->recvworkq, &args->work)
4) step 1) release the reference;
5) Finially, recvwork() will trigger UAF:
recvwork nbdconfigput(nbd) -> nbdconfig is freed atomicdec(&config->recvthreads) -> UAF
Fix the problem by clearing NBDRTBOUND in nbdgenldisconnect(), so that nbdgenlreconfigure() will fail.
In the Linux kernel, the following vulnerability has been resolved:
pfifotailenqueue: Drop new packet when sch->limit == 0
Expected behaviour: In case we reach scheduler's limit, pfifotailenqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifotailenqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifotailenqueue() return NETXMITCN status code.
Weird behaviour: In case we set sch->limit == 0 and trigger pfifotailenqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifotailenqueue() to increase qlen by one and return NETXMITCN status code.
The problem is: Let's say we have two qdiscs: QdiscA and QdiscB. - QdiscA's type must have '->graft()' function to create parent/child relationship. Let's say QdiscA's type is hfsc. Enqueue packet to this qdisc will trigger hfscenqueue. - QdiscB's type is pfifoheaddrop. Enqueue packet to this qdisc will trigger pfifotailenqueue. - QdiscB is configured to have sch->limit == 0. - QdiscA is configured to route the enqueued's packet to QdiscB.
Enqueue packet through QdiscA will lead to: - hfscenqueue(QdiscA) -> pfifotailenqueue(QdiscB) - QdiscB->q.qlen += 1 - pfifotailenqueue() return NETXMITCN - hfscenqueue() check for NETXMITSUCCESS and see NETXMITCN => hfscenqueue() don't increase qlen of QdiscA.
The whole process lead to a situation where QdiscA->q.qlen == 0 and QdiscB->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.
Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.
In the Linux kernel, the following vulnerability has been resolved:
pps: Fix a use-after-free
On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sysexit() from gpsd when rebooting:
pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobjectput() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobjectput+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobjectput+0x120/0x150 lr : kobjectput+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobjectput+0x120/0x150 cdevput+0x20/0x3c fput+0x2c4/0x2d8 fput+0x1c/0x38 taskworkrun+0x70/0xfc doexit+0x2a0/0x924 dogroupexit+0x34/0x90 getsignal+0x7fc/0x8c0 dosignal+0x128/0x13b4 donotifyresume+0xdc/0x160 el0svc+0xd4/0xf8 el0t64synchandler+0x140/0x14c el0t64sync+0x190/0x194 ---[ end trace 0000000000000000 ]---
...followed by more symptoms of corruption, with similar stacks:
refcountt: underflow; use-after-free. kernel BUG at lib/listdebug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception
This happens because ppsdevicedestruct() frees the ppsdevice with the embedded cdev immediately after calling cdevdel(), but, as the comment above cdevdel() notes, fops for previously opened cdevs are still callable even after cdevdel() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board.
In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using registerchrdev() with ppsidr becoming the source of truth for which minor corresponds to which device.
But now that ppsidr defines userspace visibility instead of cdevadd(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idrremove() call moves to ppsunregistercdev(), and ppsidr now holds a reference to pps->dev.
ppscore: source serial1 got cdev (251:1) <...> pps pps1: removed ppscore: unregistering pps1 ppscore: deallocating pps1
bpf: Prevent tail call between progs attached to different hooks
drm/amd/display: Fix slab-use-after-free in hdcp
HID: lg-g15: cancel pending work on remove to fix a use-after-free
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove
The threaded IRQ handler ccgirqhandler() calls ucsinotifycommon(), which on a connector-change event calls ucsiconnectorchange() and schedules connector work. In ucsiccgremove(), ucsidestroy() frees uc->ucsi (kfree) before freeirq() is called, so a handler invocation already in flight may access the freed object after ucsidestroy().
CPU 0 (remove) | CPU 1 (threaded IRQ) ucsidestroy(uc->ucsi) | ccgirqhandler() kfree(ucsi) // FREE | ucsinotifycommon(uc->ucsi) // USE
Move freeirq() before ucsidestroy() in the remove path. It is kept after ucsiunregister(): ucsiunregister() cancels connector work whose handler issues GETCONNECTORSTATUS through ucsisendcommandcommon(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled.
The probe error path already orders freeirq() before ucsidestroy().
This bug was found by static analysis.
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.
Last updated 25 April 2025
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.
A NULL pointer dereference flaw was found in btrfsrmdevice function in fs/btrfs/volumes.c in Linux Kernel, where triggering the bug requires ‘CAPSYSADMIN’. This could allow a local attacker to crash the system or leak kernel internal information.
References: https://lore.kernel.org/linux-btrfs/CAFcO6XO5TC5sEo-C9JGC75JkNAzkOSSLA3a=bwQqXFFbRTZ7Gw@mail.gmail.com/T/#md4b850f33616b7364f86e6fed144abc925f3669c https://lore.kernel.org/linux-btrfs/20210806102415.304717-1-wqu@suse.com/T/#u
An out of bounds (OOB) memory access flaw was found in the Linux kernel in relayfilereadstartpos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: strictly check for maximum number of actions
The maximum number of flowtable hardware offload actions in IPv6 is:
ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)
Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.
Update flowactionentrynext() calls to check for the maximum number of supported actions.
While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix filehandle bounds checking in nfsfhtodentry()
The function needs to check the minimal filehandle length before it can access the embedded filehandle.
ALSA: usb-audio: Validate UAC3 cluster segment descriptors
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix OOB and integer underflow when rx packets
Make sure mwifiexprocessmgmtpacket, mwifiexprocessstarxpacket and mwifiexprocessuaprxpacket, mwifiexuapqueuebridgedpkt and mwifiexprocessrxpacket not out-of-bounds access the skb->data buffer.