In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix use-after-free due to delegation race
A delegation break could arrive as soon as we've called vfssetlease. A delegation break runs a callback which immediately (in nfsd4cbrecallprepare) adds the delegation to delrecalllru. If we then exit nfs4setdelegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from delrecalllru.
Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread.
I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning.
In the Linux kernel, the following vulnerability has been resolved:
ethernet: hisilicon: hns: hnsdsafmisc: fix a possible array overflow in hnsdsafgesrstbyport()
The if statement: if (port >= DSAFGENUM) return;
limits the value of port less than DSAFGENUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: portrstoff = dsafdev->maccb[port]->portrstoff;
because the length of dsafdev->maccb is DSAFMAXPORTNUM (i.e., 6).
To fix this possible array overflow, we first check port and if it is greater than or equal to DSAFMAXPORTNUM, the function returns.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent underflow in nfssvcdecodewriteargs()
Smatch complains:
fs/nfsd/nfsxdr.c:341 nfssvcdecodewriteargs() warn: no lower bound on 'args->len'
Change the type to unsigned to prevent this issue.
A heap-based buffer overflow was discovered in the Linux kernel, all versions 3.x.x and 4.x.x before 4.18.0, in Marvell WiFi chip driver. The flaw could occur when the station attempts a connection negotiation during the handling of the remote devices country settings. This could allow the remote device to cause a denial of service (system crash) or possibly execute arbitrary code.
A heap-based buffer overflow vulnerability was found in the Linux kernel, version kernel-2.6.32, in Marvell WiFi chip driver. A remote attacker could cause a denial of service (system crash) or, possibly execute arbitrary code, when the lbsibssjoinexisting function is called after a STA connects to an AP.
A flaw was found in the Linux kernel's Marvell wifi chip driver. A heap overflow in mwifiexprocesstdlsactionframe function in marvell/mwifiex/tdls.c allows remote attackers to cause a denial of service(system crash) or execute arbitrary code. the station receive a tdls setup request or respone frame which the EIDSUPPRATES IE 's length is larger than 32 will cause Heap Overflow.
An issue was discovered in drivers/net/ethernet/intel/igb/igbmain.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU.
A stack-based buffer overflow was found in the Linux kernel, version kernel-2.6.32, in Marvell WiFi chip driver. An attacker is able to cause a denial of service (system crash) or, possibly execute arbitrary code, when a STA works in IBSS mode (allows connecting stations together without the use of an AP) and connects to another STA.
A vulnerability was found in technisatusb2getir in drivers/media/usb/dvb-usb/technisat-usb2.c in DVB USB subsystem, there was an out-of-bounds read for an array in struct technisatusb2state state->buf with no boundary check applied until 0xff byte is encountered, if it is not found with in the limits it goes beyond the array size, this exposes kernel data structure which should not happen.
Reference: https://lore.kernel.org/linux-media/20190821104408.w7krumcglxo6fz5q@gofer.mess.org/ https://git.linuxtv.org/mediatree.git/commit/?id=0c4df39e504bf925ab666132ac3c98d6cbbe380b https://lore.kernel.org/lkml/b9b256cb-95f2-5fa1-9956-5a602a017c11@gmail.com/
The tcpv6synrecvsock function in net/ipv6/tcpipv6.c in the Linux kernel through 4.14.11 allows attackers to cause a denial of service (slab out-of-bounds write) or possibly have unspecified other impact via vectors involving TLS.
In the Linux kernel, the following vulnerability has been resolved:
A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.
Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1
In the Linux kernel, the following vulnerability has been resolved:
inet: fully convert sk->skrxdst to RCU rules
syzbot reported various issues around early demux, one being included in this changelog [1]
sk->skrxdst is using RCU protection without clearly documenting it.
And following sequences in tcpv4dorcv()/tcpv6dorcv() are not following standard RCU rules.
[a] dstrelease(dst); [b] sk->skrxdst = NULL;
They look wrong because a delete operation of RCU protected pointer is supposed to clear the pointer before the callrcu()/synchronizercu() guarding actual memory freeing.
In some cases indeed, dst could be freed before [b] is done.
We could cheat by clearing skrxdst before calling dstrelease(), but this seems the right time to stick to standard RCU annotations and debugging facilities.
[1] BUG: KASAN: use-after-free in dstcheck include/net/dst.h:470 [inline] BUG: KASAN: use-after-free in tcpv4earlydemux+0x95b/0x960 net/ipv4/tcpipv4.c:1792 Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204
CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printaddressdescription.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247 kasanreport mm/kasan/report.c:433 [inline] kasanreport.cold+0x83/0xdf mm/kasan/report.c:450 dstcheck include/net/dst.h:470 [inline] tcpv4earlydemux+0x95b/0x960 net/ipv4/tcpipv4.c:1792 iprcvfinishcore.constprop.0+0x15de/0x1e80 net/ipv4/ipinput.c:340 iplistrcvfinish.constprop.0+0x1b2/0x6e0 net/ipv4/ipinput.c:583 ipsublistrcv net/ipv4/ipinput.c:609 [inline] iplistrcv+0x34e/0x490 net/ipv4/ipinput.c:644 netifreceiveskblistptype net/core/dev.c:5508 [inline] netifreceiveskblistcore+0x549/0x8e0 net/core/dev.c:5556 netifreceiveskblist net/core/dev.c:5608 [inline] netifreceiveskblistinternal+0x75e/0xd80 net/core/dev.c:5699 gronormallist net/core/dev.c:5853 [inline] gronormallist net/core/dev.c:5849 [inline] napicompletedone+0x1f1/0x880 net/core/dev.c:6590 virtqueuenapicomplete drivers/net/virtionet.c:339 [inline] virtnetpoll+0xca2/0x11b0 drivers/net/virtionet.c:1557 napipoll+0xaf/0x440 net/core/dev.c:7023 napipoll net/core/dev.c:7090 [inline] netrxaction+0x801/0xb40 net/core/dev.c:7177 dosoftirq+0x29b/0x9c2 kernel/softirq.c:558 invokesoftirq kernel/softirq.c:432 [inline] irqexitrcu+0x123/0x180 kernel/softirq.c:637 irqexitrcu+0x5/0x20 kernel/softirq.c:649 commoninterrupt+0x52/0xc0 arch/x86/kernel/irq.c:240 asmcommoninterrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629 RIP: 0033:0x7f5e972bfd57 Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73 RSP: 002b:00007fff8a413210 EFLAGS: 00000283 RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45 RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45 RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9 R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0 R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019 </TASK>
Allocated by task 13: kasansavestack+0x1e/0x50 mm/kasan/common.c:38 kasansettrack mm/kasan/common.c:46 [inline] setallocinfo mm/kasan/common.c:434 [inline] kasanslaballoc+0x90/0xc0 mm/kasan/common.c:467 kasanslaballoc include/linux/kasan.h:259 [inline] slabpostallochook mm/slab.h:519 [inline] slaballocnode mm/slub.c:3234 [inline] slaballoc mm/slub.c:3242 [inline] kmemcachealloc+0x202/0x3a0 mm/slub.c:3247 dstalloc+0x146/0x1f0 net/core/dst.c:92 rtdstalloc+0x73/0x430 net/ipv4/route.c:1613 iprouteinputslow+0x1817/0x3a20 net/ipv4/route.c:234 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
tipc: skblinearize the head skb when reassembling msgs
It's not a good idea to append the frag skb to a skb's fraglist if the fraglist already has skbs from elsewhere, such as this skb was created by pskbcopy() where the fraglist was cloned (all the skbs in it were skbget'ed) and shared by multiple skbs.
However, the new appended frag skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this appended frag skb are seen by multiple skbs but it only got skbget called once.
The same thing happens with a skb updated by pskbmaypull() with a skbcloned skb. Li Shuang has reported quite a few crashes caused by this when doing testing over macvlan devices:
[] kernel BUG at net/core/skbuff.c:1970! [] Call Trace: [] skbclone+0x4d/0xb0 [] macvlanbroadcast+0xd8/0x160 [macvlan] [] macvlanprocessbroadcast+0x148/0x150 [macvlan] [] processonework+0x1a7/0x360 [] workerthread+0x30/0x390
[] kernel BUG at mm/usercopy.c:102! [] Call Trace: [] checkheapobject+0xd3/0x100 [] checkobjectsize+0xff/0x16b [] simplecopytoiter+0x1c/0x30 [] skbdatagramiter+0x7d/0x310 [] skbdatagramiter+0x2a5/0x310 [] skbcopydatagramiter+0x3b/0x90 [] tipcrecvmsg+0x14a/0x3a0 [tipc] [] sysrecvmsg+0x91/0x150 [] sysrecvmsg+0x7b/0xc0
[] kernel BUG at mm/slub.c:305! [] Call Trace: [] <IRQ> [] kmemcachefree+0x3ff/0x400 [] netifreceiveskbcore+0x12c/0xc40 [] ? kmemcachealloc+0x12e/0x270 [] netifreceiveskbinternal+0x3d/0xb0 [] ? getrxpageinfo+0x8e/0xa0 [be2net] [] bepoll+0x6ef/0xd00 [be2net] [] ? irqexit+0x4f/0x100 [] netrxaction+0x149/0x3b0
...
This patch is to fix it by linearizing the head skb if it has fraglist set in tipcbufappend(). Note that we choose to do this before calling skbunshare(), as skblinearize() will avoid skbcopy(). Also, we can not just drop the fraglist either as the early time.
In the Linux kernel, the following vulnerability has been resolved:
tipc: improve size validations for received domain records
The function tipcmonrcv() allows a node to receive and process domainrecord structs from peer nodes to track their views of the network topology.
This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAXMONDOMAIN, something that may otherwise lead to a stack overflow.
tipcmonrcv() is called from the function tipclinkprotorcv(), where we are reading a 32 bit message data length field into a uint16. To avert any risk of bit overflow, we add an extra sanity check for this in that function. We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer. This potential problem was identified by Eric Dumazet.
This fixes CVE-2022-0435
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: re-fetch conntrack after insertion
In case the conntrack is clashing, insertion can free skb->nfct and set skb->nfct to the already-confirmed entry.
This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: avoid potential UAF in nvmetreqcomplete()
An nvme target ->queueresponse() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpurefput() is called in nvmetreqcomplete().
Avoid such problem by using a local variable to save the sq pointer before calling nvmetreqcomplete(), thus avoiding dereferencing the req pointer after that function call.
A flaw in the processing of received ICMP errors (ICMP fragment needed and ICMP redirect) in the Linux kernel functionality was found to allow the ability to quickly scan open UDP ports. This flaw allows an off-path remote user to effectively bypass the source port UDP randomization. The highest threat from this vulnerability is to confidentiality and possibly integrity, because software that relies on UDP source port randomization are indirectly affected as well.
Buffer overflow in i40e driver for Intel(R) Ethernet 700 Series Controllers versions before 7.0 may allow an authenticated user to potentially enable an escalation of privilege via local access.
Last updated 25 April 2025
In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.
Last updated 25 April 2025
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix listadd() corruption in lpfcdraintxq()
When parsing the txq list in lpfcdraintxq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "failmsg" string is set and a log message output. The job is then added to a completions list for cancellation.
Processing of any further jobs from the txq list continues, but since "failmsg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the failmsg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix NULL ptr dereference on VSI filter sync
Remove the reason of null pointer dereference in sync VSI filters. Added new I40EVSIRELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: sc520wdt: Fix possible use-after-free in wdtturnoff()
This module's remove path calls deltimer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free in wdtstartup()
This module's remove path calls deltimer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.
In the Linux kernel, the following vulnerability has been resolved:
wl1251: Fix possible buffer overflow in wl1251cmdscan
Function wl1251cmdscan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size.
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix double free race when mount fails in cifsgetroot()
When cifsgetroot() fails during cifssmb3domount() we call deactivatelockedsuper() which eventually will call delayedfree() which will free the context. In this situation we should not proceed to enter the out: section in cifssmb3domount() and free the same resources a second time.
[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcucblistdequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dumpstacklvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] printaddressdescription.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcucblistdequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasanreport.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcucblistdequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] asanload8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcucblistdequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcucore+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? callrcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? thiscpupreemptcheck+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lockisheldtype+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcucoresi+0xe/0x10 [Thu Feb 10 12:59:06 2022] dosoftirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] irqexitrcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irqexitrcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvechypervstimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasansavestack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasansettrack+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasansetfreeinfo+0x24/0x40 [Thu Feb 10 12:59:07 2022] kasanslabfree+0x137/0x170 [Thu Feb 10 12:59:07 2022] kasanslabfree+0x12/0x20 [Thu Feb 10 12:59:07 2022] slabfreefreelisthook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifssmb3domount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3gettree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfsgettree+0x52/0x140 [Thu Feb 10 12:59:07 2022] pathmount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] x64sysmount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] dosyscall64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entrySYSCALL64afterhwframe+0x44/0xae
[Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasansavestack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasanrecordauxstack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasanrecordauxstacknoalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] callrcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifsumount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifskillsb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivatelockedsuper+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifssmb3domount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3gettree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfsgettree+0x52/0x140 [Thu Feb 10 12:59:07 2022] pathmount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] x64sysmount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] dosyscall64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entrySYSCALL64afterhwframe+0x44/0xae
In the Linux kernel, the following vulnerability has been resolved:
can: dev: canrestart: fix use after free bug
After calling netifrxni(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is accessed after the netifrxni() in: stats->rxbytes += cf->len;
Reordering the lines solves the issue.