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

net: vertexcom: mse102x: Fix possible double free of TX skb

The scope of the TX skb is wider than just mse102xtxframespi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102xtxwork(), which leads to crashes:

Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102xtxwork [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbreleasedata+0xb8/0x1d8 lr : skbreleasedata+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skbreleasedata+0xb8/0x1d8 kfreeskbreason+0x48/0xb0 mse102xtxwork+0x164/0x35c [mse102x] processonework+0x138/0x260 workerthread+0x32c/0x438 kthread+0x118/0x11c retfromfork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)

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

skbuff: fix coalescing for pagepool fragment recycling

Fix a use-after-free when using pagepool with page fragments. We encountered this problem during normal RX in the hns3 driver:

(1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through pagepool, and the other two allocate one half of PAGE2 each. Page references look like this:

RXBD1 PAGE1 RXBD2 PAGE2 RXBD3 /

(2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcpqueuercv().

(3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netifreceiveskb():

netifreceiveskb(SKB2) iprcv(SKB2) SKB3 = skbclone(SKB2)

SKB2 and SKB3 share a reference to PAGE2 through skbshinfo()->dataref. The other ref to PAGE2 is still held by RXBD3:

SKB2 ---+- PAGE2 SKB3 / / RXBD3 /

(3b) Now while handling TCP, coalesce SKB3 with SKB1:

tcpv4rcv(SKB3) tcptrycoalesce(to=SKB1, from=SKB3) // succeeds kfreeskbpartial(SKB3) skbreleasedata(SKB3) // drops one dataref

SKB1 PAGE1 \ SKB2 PAGE2 / RXBD3 /

In skbtrycoalesce(), skbfragref() takes a page reference to PAGE2, where it should instead have increased the pagepool frag reference, ppfragcount. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow.

(3c) Drop SKB2:

afpacketrcv(SKB2) consumeskb(SKB2) skbreleasedata(SKB2) // drops second dataref pagepoolreturnskbpage(PAGE2) // drops one ppfragcount

SKB1 PAGE1 \ PAGE2 / RXBD3 /

(4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well:

tcpeatrecvskb(SKB1) skbreleasedata(SKB1) pagepoolreturnskbpage(PAGE1) pagepoolreturnskbpage(PAGE2) // drops second ppfragcount

(5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled.

Change the logic that checks whether pprecycle SKBs can be coalesced. We still reject differing pprecycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pprecycled and 'from' is cloned.

The new logic allows coalescing a cloned pprecycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skbtrycoalesce().

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

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

crypto: hisilicon/sec - fix the aead software fallback for engine

Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it.

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

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

NFSD: prevent integer overflow on 32 bit systems

On a 32 bit system, the "len sizeof(p)" operation can have an integer overflow.

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

RDMA/rtrs: Fix use-after-free in path file creation cleanup

In the error path of rtrssrvcreatepathfiles(), the sysfs root folders may already have been created and srvpath->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobjectput(&srvpath->kobj) before rtrssrvdestroyoncesysfsrootfolders(srvpath).

kobjectput() may drop the last reference to srvpath->kobj and invoke the release callback, rtrssrvrelease(), which frees srvpath. The following call to rtrssrvdestroyoncesysfsrootfolders(srvpath) then dereferences srvpath internally to access srvpath->srv, resulting in a use-after-free.

This failure path is reached before rtrssrvcreatepathfiles() returns success, so the successful-path lifetime handling is not involved.

Fix this by destroying the sysfs root folders before calling kobjectput(&srvpath->kobj), so srvpath is still valid while the helper accesses it.

This issue was found by a static analysis tool I am developing.

A flaw was found in KVM. When updating a guest's page table entry, vmpgoff was improperly used as the offset to get the page's pfn. As vaddr and vmpgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition.

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

scsi: qla2xxx: Implement ref count for SRB

The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:

qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]

Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.

When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.

If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().

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

ath11k: free peer for station when disconnect from AP for QCA6390/WCN6855

Commit b4a0f54156ac ("ath11k: move peer delete after vdev stop of station for QCA6390 and WCN6855") is to fix firmware crash by changing the WMI command sequence, but actually skip all the peer delete operation, then it lead commit 58595c9874c6 ("ath11k: Fixing dangling pointer issue upon peer delete failure") not take effect, and then happened a use-after-free warning from KASAN. because the peer->sta is not set to NULL and then used later.

Change to only skip the WMIPEERDELETECMDID for QCA6390/WCN6855.

log of user-after-free:

[ 534.888665] BUG: KASAN: use-after-free in ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860

[ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted: G W 5.15.0-wt-ath+ #523 [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 534.888716] Call Trace: [ 534.888720] <IRQ> [ 534.888726] dumpstacklvl+0x57/0x7d [ 534.888736] printaddressdescription.constprop.0+0x1f/0x170 [ 534.888745] ? ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888771] kasanreport.cold+0x83/0xdf [ 534.888783] ? ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888810] ath11kdprxupdatepeerstats+0x912/0xc10 [ath11k] [ 534.888840] ath11kdprxprocessmonstatus+0x529/0xa70 [ath11k] [ 534.888874] ? ath11kdprxmonstatusbufsreplenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? checkprevadd+0x20f0/0x20f0 [ 534.888922] ? lockacquire+0xb72/0x1870 [ 534.888937] ? findheldlock+0x33/0x110 [ 534.888954] ath11kdprxprocessmonrings+0x297/0x520 [ath11k] [ 534.888981] ? rcureadunlock+0x40/0x40 [ 534.888990] ? ath11kdprxpdevalloc+0xd90/0xd90 [ath11k] [ 534.889026] ath11kdpservicemonring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11kdprxprocessmonrings+0x520/0x520 [ath11k] [ 534.889075] calltimerfn+0x167/0x4a0 [ 534.889084] ? addtimeron+0x3b0/0x3b0 [ 534.889103] ? lockdephardirqsonprepare.part.0+0x18c/0x370 [ 534.889117] runtimers.part.0+0x539/0x8b0 [ 534.889123] ? ath11kdprxprocessmonrings+0x520/0x520 [ath11k] [ 534.889157] ? calltimerfn+0x4a0/0x4a0 [ 534.889164] ? marklockirq+0x1c30/0x1c30 [ 534.889173] ? clockeventsprogramevent+0xdd/0x280 [ 534.889189] ? markheldlocks+0xa5/0xe0 [ 534.889203] runtimersoftirq+0x97/0x180 [ 534.889213] dosoftirq+0x276/0x86a [ 534.889230] irqexitrcu+0x11c/0x180 [ 534.889238] irqexitrcu+0x5/0x20 [ 534.889244] sysvecapictimerinterrupt+0x8e/0xc0 [ 534.889251] </IRQ> [ 534.889254] <TASK> [ 534.889259] asmsysvecapictimerinterrupt+0x12/0x20 [ 534.889265] RIP: 0010:rawspinunlockirqrestore+0x38/0x70 [ 534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 0000000000000006 RBX: 0000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI: 0000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f [ 534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? marklock+0xd0/0x14a0 [ 534.889332] klistnext+0x1d4/0x450 [ 534.889340] ? dpmwaitforsubordinate+0x2d0/0x2d0 [ 534.889350] deviceforeachchild+0xa8/0x140 [ 534.889360] ? deviceremoveclasssymlinks+0x1b0/0x1b0 [ 534.889370] ? lockrelease+0x4bd/0x9f0 [ 534.889378] ? dpmsuspend+0x26b/0x3f0 [ 534.889390] dpmwaitforsubordinate+ ---truncated---

A use-after-free exists in the Linux Kernel in tcnewtfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5

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

exec: Force single empty string when argv is empty

Quoting[1] Ariadne Conill:

"In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]:

The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider.

This issue is being tracked in the KSPP issue tracker[5]."

While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs.

The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv.

Account for the additional stack space in bprmstacklimits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change:

process './argc0' launched './argc0' with NULL argv: empty string added

Additionally WARN() and reject NULL argv usage for kernel threads.

[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/showbug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+%5C%28%5B%5E%2C%5D%2B%2C+NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs%5C%28%5B%5E%2C%5D%2B%2C%5CsNULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/

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

ALSA: oss: Fix PCM OSS buffer allocation overflow

We've got syzbot reports hitting INTMAX overflow at vmalloc() allocation that is called from sndpcmplugalloc(). Although we apply the restrictions to input parameters, it's based only on the hwparams of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INTMAX, hence it hits WARNON().

This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated.

In addition, the driver uses arraysize() and array3size() for multiplications to catch overflows for the converted period size and buffer bytes.

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

uaccess: fix integer overflow on accessok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.

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

wifi: carl9170: re-fix fortified-memset warning

The carl9170txrelease() function sometimes triggers a fortified-memset warning in my randconfig builds:

In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortifymemsetchk', inlined from 'carl9170txrelease' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'krefput' at include/linux/kref.h:65:3, inlined from 'carl9170txputskb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to 'writeoverflowfield' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use structgroup()? [-Werror=attribute-warning] 493 | writeoverflowfield(psizefield, size);

Kees previously tried to avoid this by using memsetafter(), but it seems this does not fully address the problem. I noticed that the memsetafter() here is done on a different part of the union (status) than the original cast was from (ratedriverdata), which may confuse the compiler.

Unfortunately, the memsetafter() trick does not work on driverrates[] because that is part of an anonymous struct, and I could not get structgroup() to do this either. Using two separate memset() calls on the two members does address the warning though.

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

qede: confirm skb is allocated before using

qedebuildskb() assumes buildskb() always works and goes straight to skbreserve(). However, buildskb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL.

Add a check in case buildskb() failed to allocate and return NULL.

The NULL return is handled correctly in callers to qedebuildskb().

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

vfio/pci: fix memory leak during D3hot to D0 transition

If 'vfiopcicoredevice::needspmrestore' is set (PCI device does not have NoSoftReset bit set in its PMCSR config register), then the current PCI state will be saved locally in 'vfiopcicoredevice::pmsave' during D0->D3hot transition and same will be restored back during D3hot->D0 transition. For saving the PCI state locally, pcistoresavedstate() is being used and the pciloadandfreesavedstate() will free the allocated memory.

But for reset related IOCTLs, vfio driver calls PCI reset-related API's which will internally change the PCI power state back to D0. So, when the guest resumes, then it will get the current state as D0 and it will skip the call to vfiopcisetpowerstate() for changing the power state to D0 explicitly. In this case, the memory pointed by 'pmsave' will never be freed. In a malicious sequence, the state changing to D3hot followed by VFIODEVICERESET/VFIODEVICEPCIHOTRESET can be run in a loop and it can cause an OOM situation.

This patch frees the earlier allocated memory first before overwriting 'pmsave' to prevent the mentioned memory leak.

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

net: ioam6: fix OOB and missing lock

When trace->type.bit6 is set:

if (trace->type.bit6) { ... queue = skbgettxqueue(dev, skb); qdisc = rcudereference(queue->qdisc);

This code can lead to an out-of-bounds access of the dev->tx[] array when isinput is true. In such a case, the packet is on the RX path and skb->queuemapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skbgetqueuemapping(skb) will exceed dev->numtxqueues. Add a check to avoid this situation since skbgettxqueue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.

While at it, add missing lock around qdiscqstatsqlenbacklog(). The function ioam6filltracedata() is called from both softirq and process contexts, hence the use of spinlockbh() here.

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

pwm: Fix out-of-bounds access in ofpwmsinglexlate()

With args->argscount == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1].

A use-after-free flaw was found in net/sunrpc/xprt.c in the Remote Procedure Call (SunRPC) protocol in the Linux kernel. This flaw could allow a local attacker to crash, and this may even lead to a kernel information leak problem.

References:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a http://www.openwall.com/lists/oss-security/2022/04/11/4 http://www.openwall.com/lists/oss-security/2022/04/11/3

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

block: Fix iterating over an empty bio with bioforeachfolioall

If the bio contains no data, biofirstfolio() calls pagefolio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bionextfolio() to biofirstfolio().

[axboe: add unlikely() to error case]

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

platform/x86: think-lmi: Fix password opcode ordering for workstations

The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled).

Tested on some Thinkpads to confirm they are OK with this order too.

ax25: Fix netdev refcount issue

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

drivers/perf: hisipcie: Fix out-of-bound access when valid event group

The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the eventgroup array. If the number of events in an eventgroup is greater than HISIPCIEMAXCOUNTERS, the memory write overflow of eventgroup array occurs.

Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.

There are 9 different events in an eventgroup. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'

cachefiles: fix slab-use-after-free in fscachewithdrawvolume()

cachefiles: fix slab-use-after-free in cachefileswithdrawcookie()

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

PCI/MSI: Fix UAF in msicapabilityinit

KFENCE reports the following UAF:

BUG: KFENCE: use-after-free read in pcienablemsirange+0x2c0/0x488

Use-after-free read at 0x0000000024629571 (in kfence-#12): pcienablemsirange+0x2c0/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirqvectors+0x18/0x28

kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128

allocated by task 81 on cpu 7 at 10.808142s: kmemcacheallocnode+0x1f0/0x2bc kmalloctrace+0x44/0x138 msiallocdesc+0x3c/0x9c msidomaininsertmsidesc+0x30/0x78 msisetupmsidesc+0x13c/0x184 pcienablemsirange+0x258/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirqvectors+0x18/0x28

freed by task 81 on cpu 7 at 10.811436s: msidomainfreedescs+0xd4/0x10c msidomainfreelocked.part.0+0xc0/0x1d8 msidomainallocirqsalllocked+0xb4/0xbc pcimsisetupmsiirqs+0x30/0x4c pcienablemsirange+0x2a8/0x488 pciallocirqvectorsaffinity+0xec/0x14c pciallocirqvectors+0x18/0x28

Descriptor allocation done in: pcienablemsirange msicapabilityinit msisetupmsidesc msiinsertmsidesc msidomaininsertmsidesc msiallocdesc ...

Freed in case of failure in msidomainalloclocked() pcienablemsirange msicapabilityinit pcimsisetupmsiirqs msidomainallocirqsalllocked msidomainalloclocked msidomainalloclocked => fails msidomainfreelocked ...

That failure propagates back to pcimsisetupmsiirqs() in msicapabilityinit() which accesses the descriptor for unmasking in the error exit path.

Cure it by copying the descriptor and using the copy for the error exit path unmask operation.

[ tglx: Massaged change log ]

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

net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent

A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels.

Although the child shares the parent's receive channels, the number of rx queues is important for the channelstats array: the parent's rx channel index is used to access the child's channelstats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses.

This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user.