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.

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

ceph: avoid putting the realm twice when decoding snaps fails

When decoding the snaps fails it maybe leaving the 'firstrealm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUGON, etc issues.

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

cifs: Fix oops due to uncleared server->smbdconn in reconnect

In smbddestroy(), clear the server->smbdconn pointer after freeing the smbdconnection struct that it points to so that reconnection doesn't get confused.

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:

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:

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:

cifs: potential buffer overflow in handling symlinks

Smatch printed a warning: arch/x86/crypto/poly1305glue.c:198 poly1305updatearch() error: memcpy() 'dctx->buf' too small (16 vs u32max)

It's caused because Smatch marks 'linklen' as untrusted since it comes from sscanf(). Add a check to ensure that 'linklen' is not larger than the size of the 'linkstr' buffer.

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

NFSD: Prevent a potential integer overflow

If the tag length is >= U32MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decodecbcompound4res() does not have to perform arithmetic on the unsafe length value.

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

nfs: Fix KMSAN warning in decodegetfattrattrs()

Fix the following KMSAN warning:

CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BADPAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrgeneric+0x806/0xb00 nfs4xdrdecgetattr+0x1de/0x240 rpcauthunwraprespdecode+0xab/0x100 rpcauthunwrapresp+0x95/0xc0 calldecode+0x4ff/0xb50 rpcexecute+0x57b/0x19d0 rpcexecute+0x368/0x5e0 rpcruntask+0xcfe/0xee0 nfs4procgetattr+0x5b5/0x990 nfsrevalidateinode+0x477/0xd00 nfsaccessgetcached+0x1021/0x1cc0 nfsdoaccess+0x9f/0xae0 nfspermission+0x1e4/0x8c0 inodepermission+0x356/0x6c0 linkpathwalk+0x958/0x1330 pathlookupat+0xce/0x6b0 filenamelookup+0x23e/0x770 vfsstatx+0xe7/0x970 vfsfstatat+0x1f2/0x2c0 sesysnewfstatat+0x67/0x880 x64sysnewfstatat+0xbd/0x120 x64syscall+0x1826/0x3cf0 dosyscall64+0xd0/0x1b0 entrySYSCALL64afterhwframe+0x77/0x7f

The KMSAN warning is triggered in decodegetfattrattrs(), when calling decodeattrmdsthreshold(). It appears that fattr->mdsthreshold is not initialized.

Fix the issue by initializing fattr->mdsthreshold to NULL in nfsfattrinit().

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

netfilter: nfrejectipv6: fix nfrejectip6tcphdrput()

syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th->res1)

Use skbputzero() to clear the whole TCP header, as done in nfrejectiptcphdrput()

BUG: KMSAN: uninit-value in nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5661 [inline] netifreceiveskb+0x1da/0xa00 net/core/dev.c:5775 processbacklog+0x4ad/0xa50 net/core/dev.c:6108 napipoll+0xe7/0x980 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:6963 handlesoftirqs+0x1ce/0x800 kernel/softirq.c:554 dosoftirq+0x14/0x1a kernel/softirq.c:588 dosoftirq+0x9a/0x100 kernel/softirq.c:455 localbhenableip+0x9f/0xb0 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:908 [inline] devqueuexmit+0x2692/0x5610 net/core/dev.c:4450 devqueuexmit include/linux/netdevice.h:3105 [inline] neighresolveoutput+0x9ca/0xae0 net/core/neighbour.c:1565 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x2347/0x2ba0 net/ipv6/ip6output.c:141 ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0xbb8/0x14b0 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x356/0x620 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0x1ba6/0x25d0 net/ipv6/ip6output.c:366 inet6cskxmit+0x442/0x530 net/ipv6/inet6connectionsock.c:135 tcptransmitskb+0x3b07/0x4880 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpconnect+0x35b6/0x7130 net/ipv4/tcpoutput.c:4143 tcpv6connect+0x1bcc/0x1e40 net/ipv6/tcpipv6.c:333 inetstreamconnect+0x2ef/0x1730 net/ipv4/afinet.c:679 inetstreamconnect+0x6a/0xd0 net/ipv4/afinet.c:750 sysconnectfile net/socket.c:2061 [inline] sysconnect+0x606/0x690 net/socket.c:2078 dosysconnect net/socket.c:2088 [inline] sesysconnect net/socket.c:2085 [inline] x64sysconnect+0x91/0xe0 net/socket.c:2085 x64syscall+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:43 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was stored to memory at: nfrejectip6tcphdrput+0x60c/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:249 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore ---truncated---

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

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)

At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)

At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections

From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.

Send some data in both directions. Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.

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

atm: idt77252: prevent use after free in dequeuerx()

We can't dereference "skb" after calling vcc->push() because the skb is released.

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

usb: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.

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

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iwconnreqhandler() associates a new struct rdmaidprivate (connid) with an existing struct iwcmid (cmid) as follows:

connid->cmid.iw = cmid; cmid->context = connid; cmid->cmhandler = cmaiwhandler;

rdmadestroyid() frees both the cmid and the struct rdmaidprivate. Make sure that cmworkhandler() does not trigger a use-after-free by only freeing of the struct rdmaidprivate after all pending work has finished.

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

tipc: Return non-zero value from tipcudpaddr2str() on error

tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddrprintf(). Fix this by returning 1 on an invalid UDP media address.

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

libceph: fix race between delayedwork() and cephmoncstop()

The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if curmon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.

To fix this:

- clear monc->curmon and monc->hunting as part of closing the session in cephmoncstop() - bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting) - call canceldelayedworksync() after the session is closed

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:

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:

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:

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:

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:

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:

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:

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: 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:

isofs: Fix out of bound access for corrupted isofs image

When isofs image is suitably corrupted isofsreadinode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.

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

wifi: mac80211: don't return unset power in ieee80211gettxpower()

We can get a UBSAN warning if ieee80211gettxpower() returns the INTMIN value mac80211 internally uses for "unset power level".

UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dumpstack+0x74/0x92 ubsanepilogue+0x9/0x50 handleoverflow+0x8d/0xd0 ubsanhandlemuloverflow+0xe/0x10 nl80211sendiface+0x688/0x6b0 [cfg80211] [...] cfg80211registerwdev+0x78/0xb0 [cfg80211] cfg80211netdevnotifiercall+0x200/0x620 [cfg80211] [...] ieee80211ifadd+0x60e/0x8f0 [mac80211] ieee80211registerhw+0xda5/0x1170 [mac80211]

In this case, simply return an error instead, to indicate that no data is available.

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/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.