In the Linux kernel, the following vulnerability has been resolved:
net:emac/emac-mac: Fix a use after free in emacmactxbufsend
In emacmactxbufsend, it calls emactxfilltpd(..,skb,..). If some error happens in emactxfilltpd(), the skb will be freed via devkfreeskb(skb) in error branch of emactxfilltpd(). But the freed skb is still used via skb->len by netdevsentqueue(,skb->len).
As i observed that emactxfilltpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.
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:
NFS: fix an incorrect limit in filelayoutdecodelayout()
The "sizeof(struct nfsfh)" is two bytes too large and could lead to memory corruption. It should be NFSMAXFHSIZE because that's the size of the ->data[] buffer.
I reversed the size of the arguments to put the variable on the left.
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:
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:
ipv6: sr: fix invalid unregister error path
The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.
This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.
In the Linux kernel, the following vulnerability has been resolved:
net: systemport: Add global locking for descriptor lifecycle
The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues.
This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length.
The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITEPORT{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer.
The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITEPORT{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used.
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:
staging: gdm724x: fix use after free in gdmlterx()
The netifrxni() function frees the skb so we can't dereference it to save the skb->len.
In the Linux kernel, the following vulnerability has been resolved:
ila: block BH in ilaoutput()
As explained in commit 1378817486d6 ("tipc: block BH before using dstcache"), net/core/dstcache.c helpers need to be called with BH disabled.
ilaoutput() is called from lwtunneloutput() possibly from process context, and under rcureadlock().
We might be interrupted by a softirq, re-enter ilaoutput() and corrupt dstcache data structures.
Fix the race by using localbhdisable().
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.
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.
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix plock invalid read
This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plockop" and a followed sendop() will append it to a global sendlist data structure. In some cases a followed devread() moves it to recvlist and devwrite() will cast it to "struct plockxop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields.
To fix this issue the "callback" field is moved to "struct plockop" to indicate that a cast to "plockxop" is allowed and does the additional "plockxop" handling if set.
Example of the KASAN output which showed the invalid read:
[ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in devwrite+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlmcontrold/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlmcontrold Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dumpstacklvl+0x56/0x7b [ 2064.313150] printaddressdescription.constprop.8+0x21/0x150 [ 2064.314578] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.315610] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.316595] kasanreport.cold.14+0x7f/0x11b [ 2064.317674] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.318687] devwrite+0x52b/0x5a0 [dlm] [ 2064.319629] ? devread+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpflsmkernfsinitsecurity+0x10/0x10 [ 2064.321926] vfswrite+0x17e/0x930 [ 2064.322769] ? fgetlight+0x1aa/0x220 [ 2064.323753] ksyswrite+0xf1/0x1c0 [ 2064.324548] ? ia32sysread+0xb0/0xb0 [ 2064.325464] dosyscall64+0x3a/0x80 [ 2064.326387] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIGRAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasansavestack+0x1c/0x40 [ 2064.345079] kasankmalloc+0x84/0xa0 [ 2064.345933] kmemcachealloctrace+0x13b/0x220 [ 2064.346953] dlmposixunlock+0xec/0x720 [dlm] [ 2064.348811] dolockfilewait.part.32+0xca/0x1d0 [ 2064.351070] fcntlsetlk+0x281/0xbc0 [ 2064.352879] dofcntl+0x5e4/0xfe0 [ 2064.354657] x64sysfcntl+0x11f/0x170 [ 2064.356550] dosyscall64+0x3a/0x80 [ 2064.358259] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasansavestack+0x1c/0x40 [ 2064.365811] kasanrecordauxstack+0xaf/0xc0 [ 2064.368100] callrcu+0x11b/0xf70 [ 2064.369785] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.372404] receivefromsock+0x290/0x770 [dlm] [ 2064.374607] processrecvsockets+0x32/0x40 [dlm] [ 2064.377290] processonework+0x9a8/0x16e0 [ 2064.379357] workerthread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] retfromfork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasansavestack+0x1c/0x40 [ 2064.391043] kasanrecordauxstack+0xaf/0xc0 [ 2064.393303] callrcu+0x11b/0xf70 [ 2064.394885] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.397694] receivefromsock+0x290/0x770 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
In the Linux kernel, the following vulnerability has been resolved:
lwt: Fix return values of BPF xmit ops
BPF encap ops can return different types of positive values, such like NETRXDROP, NETXMITCN, NETDEVTXBUSY, and so on, from function skbdoredirect and bpflwtxmitreroute. At the xmit hook, such return values would be treated implicitly as LWTUNNELXMITCONTINUE in ip(6)finishoutput2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes.
To fix the incorrect behavior, skbdoredirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpflwtxmitreroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNELXMITCONTINUE.
In the Linux kernel, the following vulnerability has been resolved:
seg6: separate dstcache for input and output paths in seg6 lwtunnel
The seg6 lwtunnel uses a single dstcache per encap route, shared between seg6inputcore() and seg6outputcore(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.
Fix this by splitting the cache into cacheinput and cacheoutput, so each path maintains its own cached dst independently.
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 in the Linux kernel's WiFi beacon validation code was discovered. The code does not check the length of the variable length elements in the beacon head potentially leading to a buffer overflow. System availability, as well as data confidentiality and integrity, can be impacted by this vulnerability.
Last updated 4 July 2026
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.
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.
A vulnerability was found in the Linux kernel's generic WiFi ESSID handling implementation. The flaw allows a system to join a wireless network where the ESSID is longer than the maximum length of 32 characters, which can cause the system to crash or execute code.
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.
In /drivers/isdn/i4l/isdnnet.c: A user-controlled buffer is copied into a local buffer of constant size using strcpy without a length check which can cause a buffer overflow. This affects the Linux kernel 4.9-stable tree, 4.12-stable tree, 3.18-stable tree, and 4.4-stable tree.
In the Linux kernel before 4.16.4, a double free vulnerability in the fmidisetalt function of drivers/usb/gadget/function/fmidi.c in the fmidi driver may allow attackers to cause a denial of service or possibly have unspecified other impact.
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/
An issue was discovered in the Linux kernel before 5.2.3. Out of bounds access exists in the functions ath6klwmipstreamtimeouteventrx and ath6klwmicaceventrx in the file drivers/net/wireless/ath/ath6kl/wmi.c.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, addrulefg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, createflowhandle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where createflowhandle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because delswhwrule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pktreformat ids, which lead to the code in createflowhandle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes addrulefg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in createflowhandle.