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

pinctrl: aspeed: Fix potential NULL dereference in aspeedpinmuxsetmux()

pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference.

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

vlan: fix memory leak in vlannewlink()

Blamed commit added back a bug I fixed in commit 9bbd917e0bec ("vlan: fix memory leak in vlandevsetegresspriority")

If a memory allocation fails in vlanchangelink() after other allocations succeeded, we need to call vlandevfreeegresspriority() to free all allocated memory because after a failed ->newlink() we do not call any methods like ndouninit() or dev->privdestructor().

In following example, if the allocation for last element 2000:2001 fails, we need to free eight prior allocations:

ip link add link dummy0 dummy0.100 type vlan id 100 \ egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001

syzbot report was:

BUG: memory leak unreferenced object 0xffff888117bd1060 (size 32): comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s) hex dump (first 32 bytes): 09 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83fc60ad>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83fc60ad>] vlandevsetegresspriority+0xed/0x170 net/8021q/vlandev.c:193 [<ffffffff83fc6628>] vlanchangelink+0x178/0x1d0 net/8021q/vlannetlink.c:128 [<ffffffff83fc67c8>] vlannewlink+0x148/0x260 net/8021q/vlannetlink.c:185 [<ffffffff838b1278>] rtnlnewlinkcreate net/core/rtnetlink.c:3363 [inline] [<ffffffff838b1278>] rtnlnewlink+0xa58/0xdc0 net/core/rtnetlink.c:3580 [<ffffffff838b1629>] rtnlnewlink+0x49/0x70 net/core/rtnetlink.c:3593 [<ffffffff838ac66c>] rtnetlinkrcvmsg+0x21c/0x5c0 net/core/rtnetlink.c:6089 [<ffffffff839f9c37>] netlinkrcvskb+0x87/0x1d0 net/netlink/afnetlink.c:2501 [<ffffffff839f8da7>] netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] [<ffffffff839f8da7>] netlinkunicast+0x397/0x4c0 net/netlink/afnetlink.c:1345 [<ffffffff839f9266>] netlinksendmsg+0x396/0x710 net/netlink/afnetlink.c:1921 [<ffffffff8384dbf6>] socksendmsgnosec net/socket.c:714 [inline] [<ffffffff8384dbf6>] socksendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8384e15c>] syssendmsg+0x36c/0x390 net/socket.c:2488 [<ffffffff838523cb>] syssendmsg+0x8b/0xd0 net/socket.c:2542 [<ffffffff838525b8>] syssendmsg net/socket.c:2571 [inline] [<ffffffff838525b8>] dosyssendmsg net/socket.c:2580 [inline] [<ffffffff838525b8>] sesyssendmsg net/socket.c:2578 [inline] [<ffffffff838525b8>] x64syssendmsg+0x78/0xf0 net/socket.c:2578 [<ffffffff845ad8d5>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff845ad8d5>] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff8460006a>] entrySYSCALL64afterhwframe+0x46/0xb0

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

ipv6: Fix signed integer overflow in ip6appenddata

Resurrect ubsan overflow checks and ubsan report this warning, fix it by change the variable [length] type to sizet.

UBSAN: signed-integer-overflow in net/ipv6/ip6output.c:1489:19 2147479552 + 8567 cannot be represented in type 'int' CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1 Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0x214/0x230 showstack+0x30/0x78 dumpstacklvl+0xf8/0x118 dumpstack+0x18/0x30 ubsanepilogue+0x18/0x60 handleoverflow+0xd0/0xf0 ubsanhandleaddoverflow+0x34/0x44 ip6appenddata.isra.48+0x1598/0x1688 ip6appenddata+0x128/0x260 udpv6sendmsg+0x680/0xdd0 inet6sendmsg+0x54/0x90 socksendmsg+0x70/0x88 syssendmsg+0xe8/0x368 syssendmsg+0x98/0xe0 syssendmmsg+0xf4/0x3b8 arm64syssendmmsg+0x34/0x48 invokesyscall+0x64/0x160 el0svccommon.constprop.4+0x124/0x300 doel0svc+0x44/0xc8 el0svc+0x3c/0x1e8 el0t64synchandler+0x88/0xb0 el0t64sync+0x16c/0x170

Changes since v1: -Change the variable [length] type to unsigned, as Eric Dumazet suggested. Changes since v2: -Don't change exthdrlen type in ip6makeskb, as Paolo Abeni suggested. Changes since v3: -Don't change ulen type in udpv6sendmsg and l2tpip6sendmsg, as Jakub Kicinski suggested.

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

ipv6: fix lockdep splat in in6dumpaddrs()

As reported by syzbot, we should not use rcudereference() when rcureadlock() is not held.

WARNING: suspicious RCU usage 5.19.0-rc2-syzkaller #0 Not tainted

net/ipv6/addrconf.c:5175 suspicious rcudereferencecheck() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnlmutex){+.+.}-{3:3}, at: netlinkdump+0xae/0xc20 net/netlink/afnetlink.c:2223

stack backtrace: CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-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 in6dumpaddrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6dumpaddr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlinkdump+0x541/0xc20 net/netlink/afnetlink.c:2275 netlinkdumpstart+0x647/0x900 net/netlink/afnetlink.c:2380 netlinkdumpstart include/linux/netlink.h:245 [inline] rtnetlinkrcvmsg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlinkrcvskb+0x153/0x420 net/netlink/afnetlink.c:2501 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x543/0x7f0 net/netlink/afnetlink.c:1345 netlinksendmsg+0x917/0xe10 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0xcf/0x120 net/socket.c:734 syssendmsg+0x6eb/0x810 net/socket.c:2492 syssendmsg+0xf3/0x170 net/socket.c:2546 syssendmsg net/socket.c:2575 [inline] dosyssendmsg net/socket.c:2584 [inline] sesyssendmsg net/socket.c:2582 [inline] x64syssendmsg+0x132/0x220 net/socket.c:2582 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x46/0xb0

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

tracing/histograms: Fix memory leak problem

This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.

As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: In parsevardefs() if there is a problem allocating vardefs.expr, the earlier vardefs.name is freed. This free is duplicated by freevardefs() which frees the rest of the list.

However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed;

IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------

These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed.

If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [0000000038fe4895] kstrdup+0x2d/0x60 [00000000c99c049a] eventhisttriggerparse+0x206f/0x20e0 [00000000ae70d2cc] triggerprocessregex+0xc0/0x110 [0000000066737a4c] eventtriggerwrite+0x75/0xd0 [000000007341e40c] vfswrite+0xbb/0x2a0 [0000000087fde4c2] ksyswrite+0x59/0xd0 [00000000581e9cdf] dosyscall64+0x3a/0x80 [00000000cf3b065c] entrySYSCALL64afterhwframe+0x46/0xb0

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

ima: Fix potential memory leak in imainitcrypto()

On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the imaalgoarray. Add the missing kfree() for imaalgoarray to avoid the potential memory leak.

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

usbnet: fix memory leak in error case

usbnetwritecmdasync() mixed up which buffers need to be freed in which error case.

v2: add Fixes tag v3: fix uninitialized buf pointer

A NULL pointer dereference issue was discovered in the Linux kernel in the MPTCP protocol when traversing the subflow list at disconnect time. A local user could use this flaw to potentially crash the system causing a denial of service.

A NULL pointer dereference issue was discovered in the Linux kernel in iofilesupdatewithindexalloc. A local user could use this flaw to potentially crash the system causing a denial of service.

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

usb: dwc2: Fix memory leak in dwc2hcdinit

usbcreatehcd will alloc memory for hcd, and we should call usbputhcd to free it when platformgetresource() fails to prevent memory leak. goto error2 label instead error1 to fix this.

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

ext4: fix bugon ext4mbuseinodepa

Hulk Robot reported a BUGON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4mbmarkdiskspaceused.cold+0x85/0x136f [...] Call Trace: ext4mbnewblocks+0x9df/0x5d30 ext4extmapblocks+0x1803/0x4d80 ext4mapblocks+0x3a4/0x1a10 ext4writepages+0x126d/0x2c30 dowritepages+0x7f/0x1b0 filemapfdatawriterange+0x285/0x3b0 filewriteandwaitrange+0xb1/0x140 ext4syncfile+0x1aa/0xca0 vfsfsyncrange+0xfb/0x260 dofsync+0x48/0xa0 [...] ==================================================================

Above issue may happen as follows: ------------------------------------- dofsync vfsfsyncrange ext4syncfile filewriteandwaitrange filemapfdatawriterange dowritepages ext4writepages mpagemapandsubmitextent mpagemaponeextent ext4mapblocks ext4mbnewblocks ext4mbnormalizerequest >>> start + size <= ac->acoex.felogical ext4mbregularallocator ext4mbsimplescangroup ext4mbusebestfound ext4mbnewpreallocation ext4mbnewinodepa ext4mbuseinodepa >>> set ac->acbex.felen <= 0 ext4mbmarkdiskspaceused >>> BUGON(ac->acbex.felen <= 0);

we can easily reproduce this problem with the following commands: fallocate -l100M disk mkfs.ext4 -b 1024 -g 256 disk mount disk /mnt fsstress -d /mnt -l 0 -n 1000 -p 1

The size must be smaller than or equal to EXT4BLOCKSPERGROUP. Therefore, "start + size <= ac->acoex.felogical" may occur when the size is truncated. So start should be the start position of the group where acoex.felogical is located after alignment. In addition, when the value of felogical or EXT4BLOCKSPERGROUP is very large, the value calculated by startoff is more accurate.

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

afs: Fix dynamic root getattr

The recent patch to make afsgetattr consult the server didn't account for the pseudo-inodes employed by the dynamic root-type afs superblock not having a volume or a server to access, and thus an oops occurs if such a directory is stat'd.

Fix this by checking to see if the vnode->volume pointer actually points anywhere before following it in afsgetattr().

This can be tested by stat'ing a directory in /afs. It may be sufficient just to do "ls /afs" and the oops looks something like:

BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:afsgetattr+0x8b/0x14b ... Call Trace: <TASK> vfsstatx+0x79/0xf5 vfsfstatat+0x49/0x62

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

powerpc/memhotplug: Add addpages override for PPC

With commit ffa0b64e3be5 ("powerpc: Fix virtaddrvalid() for 64-bit Book3E & 32-bit") the kernel now validate the addr against highmemory value. This results in the below BUGON with dax pfns.

[ 635.798741][T26531] kernel BUG at mm/pagealloc.c:5521! 1:mon> e cpu 0x1: Vector: 700 (Program Check) at [c000000007287630] pc: c00000000055ed48: freepages.part.0+0x48/0x110 lr: c00000000053ca70: tlbfinishmmu+0x80/0xd0 sp: c0000000072878d0 msr: 800000000282b033 current = 0xc00000000afabe00 paca = 0xc00000037ffff300 irqmask: 0x03 irqhappened: 0x05 pid = 26531, comm = 50-landscape-sy kernel BUG at :5521! Linux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022 1:mon> t [link register ] c00000000053ca70 tlbfinishmmu+0x80/0xd0 [c0000000072878d0] c00000000053ca54 tlbfinishmmu+0x64/0xd0 (unreliable) [c000000007287900] c000000000539424 exitmmap+0xe4/0x2a0 [c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210 [c000000007287a20] c000000000629230 beginnewexec+0x5e0/0xf40 [c000000007287ae0] c00000000070b3cc loadelfbinary+0x3ac/0x1e00 [c000000007287c10] c000000000627af0 bprmexecve+0x3b0/0xaf0 [c000000007287cd0] c000000000628414 doexecveatcommon.isra.0+0x1e4/0x310 [c000000007287d80] c00000000062858c sysexecve+0x4c/0x60 [c000000007287db0] c00000000002c1b0 systemcallexception+0x160/0x2c0 [c000000007287e10] c00000000000c53c systemcallcommon+0xec/0x250

The fix is to make sure we update highmemory on memory hotplug. This is similar to what x86 does in commit 3072e413e305 ("mm/memoryhotplug: introduce addpages")

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

i2c: piix4: Fix a memory leak in the EFCH MMIO support

The recently added support for EFCH MMIO regions introduced a memory leak in that code path. The leak is caused by the fact that releaseresource() merely removes the resource from the tree but does not free its memory. We need to call releasememregion() instead, which does free the memory. As a nice side effect, this brings back some symmetry between the legacy and MMIO paths.

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

sysctl: Fix data races in procdouintvec().

A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing.

This patch changes procdouintvec() to use READONCE() and WRITEONCE() internally to fix data-races on the sysctl side. For now, procdouintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.

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

net: atlantic: remove aqnicdeinit() when resume

aqnicdeinit() has been called while suspending, so we don't have to call it again on resume. Actually, call it again leads to another hang issue when resuming from S3.

Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace: Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346] <TASK> Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992348] aqnicdeinit+0xb4/0xd0 [atlantic] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992356] aqpmthaw+0x7f/0x100 [atlantic] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992362] pcipmresume+0x5c/0x90 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992366] ? pcipmthaw+0x80/0x80 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992368] dpmruncallback+0x4e/0x120 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992371] deviceresume+0xad/0x200 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992373] asyncresume+0x1e/0x40 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992374] asyncrunentryfn+0x33/0x120 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992377] processonework+0x220/0x3c0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992380] workerthread+0x4d/0x3f0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992382] ? processonework+0x3c0/0x3c0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992384] kthread+0x12a/0x150 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992386] ? setkthreadstruct+0x40/0x40 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992387] retfromfork+0x22/0x30 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992391] </TASK> Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992392] ---[ end trace 1ec8c79604ed5e0d ]--- Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992394] PM: dpmruncallback(): pcipmresume+0x0/0x90 returns -110 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992397] atlantic 0000:02:00.0: PM: failed to resume async: error -110

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

x86/speculation: Fill RSB on vmexit for IBRS

Prevent RSB underflow/poisoning attacks with RSB. While at it, add a bunch of comments to attempt to document the current state of tribal knowledge about RSB attacks and what exactly is being mitigated.

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

KVM: VMX: Prevent RSB underflow before vmenter

On VMX, there are some balanced returns between the time the guest's SPECCTRL value is written, and the vmenter.

Balanced returns (matched by a preceding call) are usually ok, but it's at least theoretically possible an NMI with a deep call stack could empty the RSB before one of the returns.

For maximum paranoia, don't allow any returns (balanced or otherwise) between the SPECCTRL write and the vmenter.

[ bp: Fix 32-bit build. ]

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

perf/core: Fix data race between perfeventsetoutput() and perfmmapclose()

Yang Jihing reported a race between perfeventsetoutput() and perfmmapclose():

CPU1 CPU2

perfmmapclose(e2) if (atomicdecandtest(&e2->rb->mmapcount)) // 1 - > 0 detachrest = true

ioctl(e1, IOCSETOUTPUT, e2) perfeventsetoutput(e1, e2)

... listforeachentryrcu(e, &e2->rb->eventlist, rbentry) ringbufferattach(e, NULL); // e1 isn't yet added and // therefore not detached

ringbufferattach(e1, e2->rb) listaddrcu(&e1->rbentry, &e2->rb->eventlist)

After this; e1 is attached to an unmapped rb and a subsequent perfmmap() will loop forever more:

again: mutexlock(&e->mmapmutex); if (event->rb) { ... if (!atomicincnotzero(&e->rb->mmapcount)) { ... mutexunlock(&e->mmapmutex); goto again; } }

The loop in perfmmapclose() holds e2->mmapmutex, while the attach in perfeventsetoutput() holds e1->mmapmutex. As such there is no serialization to avoid this race.

Change perfeventsetoutput() to take both e1->mmapmutex and e2->mmapmutex to alleviate that problem. Additionally, have the loop in perfmmap() detach the rb directly, this avoids having to wait for the concurrent perfmmapclose() to get around to doing it to make progress.

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

tcp: Fix data-races around sysctltcpminsndmss.

While reading sysctltcpminsndmss, it can be changed concurrently. Thus, we need to add READONCE() to its readers.

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

tcp: Fix data-races around sysctltcpmigratereq.

While reading sysctltcpmigratereq, it can be changed concurrently. Thus, we need to add READONCE() to its readers.

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

iavf: Fix handling of dummy receive descriptors

Fix memory leak caused by not handling dummy receive descriptor properly. iavfgetrxbuffer now sets the rxbuffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen.

[Jesse: massaged commit message]

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

afunix: Fix a data-race in unixdgrampeerwakeme().

unixdgrampoll() calls unixdgrampeerwakeme() without other's lock held and check if its receive queue is full. Here we need to use unixrecvqfulllockless() instead of unixrecvqfull(), otherwise KCSAN will report a data-race.

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

net/mlx5: E-Switch, pair only capable devices

OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities.

This fixes an issue where mlx5getnextphysdev() was called without holding the interface lock.

This issue was found when commit bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices") added an assert that verifies the interface lock is held.

WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5getnextphysdev+0xd2/0x100 [mlx5core] Modules linked in: mlx5vdpa vringh vhostiotlb vdpa mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm ibuverbs ibcore overlay fuse [last unloaded: mlx5core] CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5getnextphysdev+0xd2/0x100 [mlx5core] Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mlx5eswoffloadsdevcomevent+0x99/0x3b0 [mlx5core] mlx5devcomsendevent+0x167/0x1d0 [mlx5core] eswoffloadsenable+0x1153/0x1500 [mlx5core] ? mlx5eswoffloadscontrollervalid+0x170/0x170 [mlx5core] ? waitforcompletioniotimeout+0x20/0x20 ? mlx5rescandriverslocked+0x318/0x810 [mlx5core] mlx5eswitchenablelocked+0x586/0xc50 [mlx5core] ? mlx5eswitchdisablepfvfvports+0x1d0/0x1d0 [mlx5core] ? mlx5eswtrylock+0x1b/0xb0 [mlx5core] ? mlx5eswitchenable+0x270/0x270 [mlx5core] ? debugfscreatefile+0x260/0x3e0 mlx5devlinkeswitchmodeset+0x27e/0x870 [mlx5core] ? mutexlockionested+0x12c0/0x12c0 ? eswoffloadsdisable+0x250/0x250 [mlx5core] ? devlinknlcmdtrapgetdumpit+0x470/0x470 ? rcureadlockschedheld+0x3f/0x70 devlinknlcmdeswitchsetdoit+0x217/0x620

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

sock: redo the psock vs ULP protection check

Commit 8a59f9d1e3d4 ("sock: Introduce sk->skprot->psockupdateskprot()") has moved the inetcskhasulp(sk) check from skpsockinit() to the new tcpbpfupdateproto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets.

Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the skpsockinit() itself. Otherwise if ULP is already present we'll notice that later, and call tcpupdateulp() with the skproto of the ULP itself, which will most likely result in the ULP looping its callbacks.

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

ata: libata-core: fix NULL pointer deref in atahostallocpinfo()

In an unlikely (and probably wrong?) case that the 'ppi' parameter of atahostallocpinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&atadummyportinfo' to fix the possible kernel oops for good...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.

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

nfc: nfcmrvl: Fix memory leak in nfcmrvlplaydeferred

Similar to the handling of playdeferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in playdeferred"), we thought a patch might be needed here as well.

Currently usbsubmiturb is called directly to submit deferred tx urbs after unanchor them.

So the usbgivebackurbbh would failed to unref it in usbunanchorurb and cause memory leak.

Put those urbs in txanchor to avoid the leak, and also fix the error handling.

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

ipv6: Fix signed integer overflow in l2tpip6sendmsg

When len >= INTMAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.

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

clocksource: hyper-v: unexport init-annotated hvinitclocksource()

EXPORTSYMBOL and init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated init. The access to a freed symbol may end up with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds.

There are two ways to fix it:

- Remove init - Remove EXPORTSYMBOL

I chose the latter for this case because the only in-tree call-site, arch/x86/kernel/cpu/mshyperv.c is never compiled as modular. (CONFIGHYPERVISORGUEST is boolean)

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

drm/i915/reset: Fix errorstateread ptr + offset use

Fix our pointer offset usage in errorstateread when there is no i915gpucoredump but buf offset is non-zero.

This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 errorstate dump while the other is forcing full GT resets. (takes a while to trigger).

The dmesg call trace:

[ 5590.803000] BUG: unable to handle page fault for address: ffffffffa0b0e000 [ 5590.803009] #PF: supervisor read access in kernel mode [ 5590.803013] #PF: errorcode(0x0000) - not-present page [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067 PTE 0 [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 5590.803026] CPU: 5 PID: 13656 Comm: i915hangman Tainted: G U 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136 [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00. 3031.A02.2201171222 01/17/2022 [ 5590.803039] RIP: 0010:memcpyerms+0x6/0x10 [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282 [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00 RCX: 0000000000000f8f [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000 RDI: ffff888107ee9071 [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000019 [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000 R15: ffff888107ee9000 [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000) knlGS:0000000000000000 [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004 CR4: 0000000000770ee0 [ 5590.803089] PKRU: 55555554 [ 5590.803091] Call Trace: [ 5590.803093] <TASK> [ 5590.803096] errorstateread+0xa1/0xd0 [i915] [ 5590.803175] kernfsfopreaditer+0xb2/0x1b0 [ 5590.803180] newsyncread+0x116/0x1a0 [ 5590.803185] vfsread+0x114/0x1b0 [ 5590.803189] ksysread+0x63/0xe0 [ 5590.803193] dosyscall64+0x38/0xc0 [ 5590.803197] entrySYSCALL64afterhwframe+0x44/0xae [ 5590.803201] RIP: 0033:0x7f62aaea5912 [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000 RCX: 00007f62aaea5912 [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f RDI: 0000000000000006 [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010 R09: 0000000000101000 [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000006 [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010 R15: 0000000000200000 [ 5590.803238] </TASK> [ 5590.803240] Modules linked in: i915 ttm drmbuddy drmdphelper drmkmshelper syscopyarea sysfillrect sysimgblt fbsysfops primenumbers nfnetlink brnetfilter overlay meipxp meihdcp x86pkgtempthermal coretemp kvmintel sndhdacodechdmi sndhdaintel ---truncated---