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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.

OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.

ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.

The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.

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

netfilter: socket: Lookup orig tuple for IPv6 SNAT

nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.

However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.

IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.

Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe, resulting in arbitrary read/write in kernel memory, lateral privilege escalation, and container escape.

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:

net: lantiq: fix memory corruption in RX ring

In a situation where memory allocation or dma mapping fails, an invalid address is programmed into the descriptor. This can lead to memory corruption. If the memory allocation fails, DMA should reuse the previous skb and mapping and drop the packet. This patch also increments rx drop counter.

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:

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

nvme-tcp: fix UAF when detecting digest errors

The Linux kernel CVE team has assigned CVE-2022-48686 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050342-CVE-2022-48686-5e8e@gregkh/T

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

nvmet: fix a use-after-free

Fix the following use-after-free complaint triggered by blktests nvme/004:

BUG: KASAN: user-memory-access in blkmqcompleterequestremote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvmeloopexecutework [nvmeloop] Call Trace: showstack+0x52/0x58 dumpstacklvl+0x49/0x5e printreport.cold+0x36/0x1e2 kasanreport+0xb9/0xf0 asanload4+0x6b/0x80 blkmqcompleterequestremote+0xac/0x350 nvmeloopqueueresponse+0x1df/0x275 [nvmeloop] nvmetreqcomplete+0x132/0x4f0 [nvmet] nvmetreqcomplete+0x15/0x40 [nvmet] nvmetexecuteioconnect+0x18a/0x1f0 [nvmet] nvmeloopexecutework+0x20/0x30 [nvmeloop] processonework+0x56e/0xa70 workerthread+0x2d1/0x640 kthread+0x183/0x1c0 retfromfork+0x1f/0x30

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

can: j1939: fix Use-after-Free, hold skb ref while in use

This patch fixes a Use-after-Free found by the syzbot.

The problem is that a skb is taken from the per-session skb queue, without incrementing the ref count. This leads to a Use-after-Free if the skb is taken concurrently from the session queue due to a CTS.

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

scsi: iscsi: Fix conn use after free during resets

If we haven't done a unbind target call we can race where iscsiconnteardown wakes up the EH thread and then frees the conn while those threads are still accessing the conn ehwait.

We can only do one TMF per session so this just moves the TMF fields from the conn to the session. We can then rely on the iscsisessionteardown->iscsiremovesession->iscsiunbindsession call to remove the target and it's devices, and know after that point there is no device or scsi-ml callout trying to access the session.

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

net/tls: Fix flipped sign in tlserrabort() calls

sk->skerr appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance,

[kworker] tlsencryptdone(..., err=<negative error from crypto request>) tlserrabort(.., err) sk->skerr = err;

[task] splicefrompipefeed ... tlsswdosendpage if (sk->skerr) { ret = -sk->skerr; // ret is positive

splicefrompipefeed (continued) ret = actor(...) // ret is still positive and interpreted as bytes // written, resulting in underflow of buf->len and // sd->len, leading to huge buf->offset and bogus // addresses computed in later calls to actor()

Fix all tlserrabort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once.

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:

net/smc: fix wrong listdel in smclgrcleanupearly

smclgrcleanupearly() meant to delete the link group from the link group list, but it deleted the list head by mistake.

This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing:

[  231.277259] listdel corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [  231.278222] ------------[ cut here ]------------ [  231.278726] kernel BUG at lib/listdebug.c:53! [  231.279326] invalid opcode: 0000 [#1] SMP NOPTI [  231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [  231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [  231.281248] Workqueue: events smclinkdownwork [  231.281732] RIP: 0010:listdelentryvalid+0x70/0x90 [  231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [  231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [  231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [  231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [  231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [  231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [  231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [  231.288337] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [  231.289160] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [  231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  231.291940] Call Trace: [  231.292211]  smclgrterminatesched+0x53/0xa0 [  231.292677]  smcswitchconns+0x75/0x6b0 [  231.293085]  ? updateloadavg+0x1a6/0x590 [  231.293517]  ? ttwudowakeup+0x17/0x150 [  231.293907]  ? updateloadavg+0x1a6/0x590 [  231.294317]  ? newidlebalance+0xca/0x3d0 [  231.294716]  smcrlinkdown+0x50/0x1a0 [  231.295090]  ? wakeupcommonlock+0x77/0x90 [  231.295534]  smclinkdownwork+0x46/0x60 [  231.295933]  processonework+0x18b/0x350

Dear Linux Developers,

We're reaching out to you as part of the disclosure process of our research.

In our research, which we will present at IEEE Security & Privacy in May 2024, we found that attackers can not only create TCP-spoofed connections (which was already known), but can also reliably transmit IP-spoofed data over such connections. This has security implications for applications that rely on TCP endpoint IP addresses, such as firewalling or host-based authentication (e.g., SMTP/SPF, of DBs).

We basically discovered two TCP spoofing primitives. First, attackers can bruteforce the server-chosen send window by acknowledging data that was never sent (what we call "ghost ACKs"; see Figure 3 in the paper). Second, we show that there are side channels that allow the attacker to leak the otherwise-secret server-chosen initial sequence number (ISN). One of these side channels leverages TCP SYN cookies.

We believe that the TCP/IP stack can take countermeasures to prevent such attacks, or at least make them harder. For example, we think that TCP endpoints should ignore ghost ACKs, and have some ideas to randomize the TCP backlog queue to prevent the SYN cookie side channel.

At the same time, we have disclosed our findings to the IETF folks and hope that they have helpful feedback for us.

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

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipcbufappend() error path:

BUG: KASAN: slab-use-after-free in kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> dumpstack linux/lib/dumpstack.c:88 dumpstacklvl+0xd9/0x1b0 linux/lib/dumpstack.c:106 printaddressdescription linux/mm/kasan/report.c:377 printreport+0xc4/0x620 linux/mm/kasan/report.c:488 kasanreport+0xda/0x110 linux/mm/kasan/report.c:601 kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skbreleasedata+0x5af/0x880 linux/net/core/skbuff.c:1026 skbreleaseall linux/net/core/skbuff.c:1094 kfreeskb linux/net/core/skbuff.c:1108 kfreeskbreason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfreeskb linux/./include/linux/skbuff.h:1244 tipcbufappend+0x425/0xb50 linux/net/tipc/msg.c:186 tipclinkinput+0x224/0x7c0 linux/net/tipc/link.c:1324 tipclinkrcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipcrcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipcudprecv+0x73b/0x8f0 linux/net/tipc/udpmedia.c:390 udpqueuercvoneskb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udpqueuercvskb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udpunicastrcvskb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 udp4librcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ipprotocoldeliverrcu+0x30c/0x4e0 linux/net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2e4/0x520 linux/net/ipv4/ipinput.c:233 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iplocaldeliver+0x18e/0x1f0 linux/net/ipv4/ipinput.c:254 dstinput linux/./include/net/dst.h:461 iprcvfinish linux/net/ipv4/ipinput.c:449 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iprcv+0x2c5/0x5d0 linux/net/ipv4/ipinput.c:569 netifreceiveskbonecore+0x199/0x1e0 linux/net/core/dev.c:5534 netifreceiveskb+0x1f/0x1c0 linux/net/core/dev.c:5648 processbacklog+0x101/0x6b0 linux/net/core/dev.c:5976 napipoll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napipoll linux/net/core/dev.c:6645 netrxaction+0x95a/0xe90 linux/net/core/dev.c:6781 dosoftirq+0x21f/0x8e7 linux/kernel/softirq.c:553 dosoftirq linux/kernel/softirq.c:454 dosoftirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> localbhenableip+0x100/0x120 linux/kernel/softirq.c:381 localbhenable linux/./include/linux/bottomhalf.h:33 rcureadunlockbh linux/./include/linux/rcupdate.h:851 devqueuexmit+0x871/0x3ee0 linux/net/core/dev.c:4378 devqueuexmit linux/./include/linux/netdevice.h:3169 neighhhoutput linux/./include/net/neighbour.h:526 neighoutput linux/./include/net/neighbour.h:540 ipfinishoutput2+0x169f/0x2550 linux/net/ipv4/ipoutput.c:235 ipfinishoutput linux/net/ipv4/ipoutput.c:313 ipfinishoutput+0x49e/0x950 linux/net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 linux/net/ipv4/ipoutput.c:323 NFHOOKCOND linux/./include/linux/netfilter.h:303 ipoutput+0x13b/0x2a0 linux/net/ipv4/ipoutput.c:433 dstoutput linux/./include/net/dst.h:451 iplocalout linux/net/ipv4/ipoutput.c:129 ipsendskb+0x3e5/0x560 linux/net/ipv4/ipoutput.c:1492 udpsendskb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udpsendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inetsendmsg+0x105/0x140 linux/net/ipv4/afinet.c:850 socksendmsgnosec linux/net/socket.c:730 socksendmsg linux/net/socket.c:745 syssendto+0x42c/0x4e0 linux/net/socket.c:2191 dosyssendto linux/net/socket.c:2203 sesyssendto linux/net/socket.c:2199 x64syssendto+0xe0/0x1c0 linux/net/socket.c:2199 dosyscallx64 linux/arch/x86/entry/common.c:52 dosyscall ---truncated---

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

of: module: add buffer overflow check in ofmodalias()

In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).

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

RDMA/rxe: Fix seg fault in rxecompqueuepkt

In rxecompqueuepkt() an incoming response packet skb is enqueued to the resppkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.

This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.

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:

tipc: force a dst refcount before doing decryption

As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"):

"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."

On TIPC decryption path it has the same problem, and skbdstforce() should be called before doing decryption to avoid a possible crash.

Shuang reported this issue when this warning is triggered:

[] WARNING: include/net/dst.h:337 tipcskrcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x8664+debug [] Workqueue: crypto cryptdqueueworker [] RIP: 0010:tipcskrcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipcskmcastrcv+0x548/0xea0 [tipc] [] tipcrcv+0xcf5/0x1060 [tipc] [] tipcaeaddecryptdone+0x215/0x2e0 [tipc] [] cryptdaeadcrypt+0xdb/0x190 [] cryptdqueueworker+0xed/0x190 [] processonework+0x93d/0x17e0

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

nvme: fix a possible use-after-free in controller reset during load

Unlike .queuerq, in .submitasyncevent drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.

The race condition may happen in the following scenario: 1. driver executes its resetctrlwork 2. -> nvmestopctrl - flushes ctrl asynceventwork 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free

In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission.

This addresses the above race in controller resets because the driver during teardown should: 1. change ctrl state to RESETTING 2. flush asynceventwork (as well as other async work elements)

So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER.

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

nvme-rdma: fix possible use-after-free in transport errorrecovery work

While nvmerdmasubmitasynceventwork is checking the ctrl and queue state before preparing the AER command and scheduling iowork, in order to fully prevent a race where this check is not reliable the error recovery work must flush asynceventwork before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submitasyncevent and the error recovery handler itself changing the ctrl state.

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

nvme-tcp: fix possible use-after-free in transport errorrecovery work

While nvmetcpsubmitasynceventwork is checking the ctrl and queue state before preparing the AER command and scheduling iowork, in order to fully prevent a race where this check is not reliable the error recovery work must flush asynceventwork before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submitasyncevent and the error recovery handler itself changing the ctrl state.

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().