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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.

OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.

IBM Security Verify Access uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

IBM Security Verify Access could allow an attacker with read-only privileges to make unauthorized modifications and deployments outside of their assigned permissions.

Quadratic complexity in node ID cache clearing

A critical stack overflow vulnerability was discovered in the libxslt library when handling the dyn:map() function from the EXSLT extension. The vulnerability allows an attacker to cause a denial of service (DoS) via a specially crafted XSLT document containing the recursive dyn:map(., .) call.

The main reason of the vulnerability is that the exsltDynMapFunction function in libexslt/dynamic.c doesn’t contain a recursion depth check. When handling dyn:map(., .) where the second parameter contains a recursive call to the same function, infinite recursion occurs until the program stack is exhausted.

A flaw was found in util-linux. Heap buffer overread when processing 256-byte usernames. Affects any SUID login-utils utility writing to password database. The setpwnam() function allocates a 256-byte buffer but accesses linebuf[256] when username length equals 256, causing a heap buffer overread.

Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation which can trigger a stack-based buffer overflow, invalid pointer or NULL pointer dereference during MAC verification.

Impact summary: The stack buffer overflow or NULL pointer dereference may cause a crash leading to Denial of Service for an application that parses untrusted PKCS#12 files. The buffer overflow may also potentially enable code execution depending on platform mitigations.

When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2 salt and keylength parameters from the file are used without validation. If the value of keylength exceeds the size of the fixed stack buffer used for the derived key (64 bytes), the key derivation will overflow the buffer. The overflow length is attacker-controlled. Also, if the salt parameter is not an OCTET STRING type this can lead to invalid or NULL pointer dereference.

Exploiting this issue requires a user or application to process a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted PKCS#12 files in applications as they are usually used to store private keys which are trusted by definition. For this reason the issue was assessed as Moderate severity.

The FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as PKCS#12 processing is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.

OpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do not support PBMAC1 in PKCS#12.

IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 and IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 could allow a remote attacker to conduct phishing attacks, caused by an open redirect vulnerability. An attacker could exploit this vulnerability using a specially crafted request to redirect a victim to arbitrary Web sites.

An attacker can cause per-connection memory allocations of up to approximately 22 MiB and extra CPU work, potentially leading to service degradation or resource exhaustion (Denial of Service).

In affected configurations, the peer-supplied uncompressed certificate length from a CompressedCertificate message is used to grow a heap buffer prior to decompression. This length is not bounded by the maxcertlist setting, which otherwise constrains certificate message sizes. An attacker can exploit this to cause large per-connection allocations followed by handshake failure. No memory corruption or information disclosure occurs.

This issue only affects builds where TLS 1.3 certificate compression is compiled in (i.e., not OPENSSLNOCOMPALG) and at least one compression algorithm (brotli, zlib, or zstd) is available, and where the compression extension is negotiated. Both clients receiving a server CompressedCertificate and servers in mutual TLS scenarios receiving a client CompressedCertificate are affected. Servers that do not request client certificates are not vulnerable to client-initiated attacks.

Users can mitigate this issue by setting SSLOPNORXCERTIFICATECOMPRESSION to disable receiving compressed certificates.

The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the TLS implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

A NULL pointer dereference leads to abnormal termination of the running process causing Denial of Service.

Some applications call SSLCIPHERfind() from the clienthellocb callback on the cipher ID received from the peer. If this is done with an SSL object implementing the QUIC protocol, NULL pointer dereference will happen if the examined cipher ID is unknown or unsupported.

As it is not very common to call this function in applications using the QUIC protocol and the worst outcome is Denial of Service, the issue was assessed as Low severity.

The vulnerable code was introduced in the 3.2 version with the addition of the QUIC protocol support.

The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue, as the QUIC implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 3.6 users should upgrade to OpenSSL 3.6.1.

OpenSSL 3.5 users should upgrade to OpenSSL 3.5.5.

OpenSSL 3.4 users should upgrade to OpenSSL 3.4.4.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.6.

A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information.

A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.

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

soc: qcom: cmd-db: Map shared memory as WC, not WB

Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.

The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.

Changing the mapping of cmd-db memory from MEMREMAPWB to MEMREMAPWT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAPWC.

I tested this on SA8155P with Xen.

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

iouring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.

Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.

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

can: mcan: pci: add missing mcanclassfreedev() in probe/remove methods

In mcanpciremove() and error handling path of mcanpciprobe(), mcanclassfreedev() should be called to free resource allocated by mcanclassallocatedev(), otherwise there will be memleak.

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

virtio/vsock: Fix acceptqueue memory leak

As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.

vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release

Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromforkasm+0x1a/0x30

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

x86/xen: don't do PV iret hypercall through hypercall page

Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S.

This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations.

This is part of XSA-466 / CVE-2024-53241.

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

RDMA/rxe: Fix the qp flush warnings in req

When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.

[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxecomp.c:756 rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.617744] Modules linked in: rnbdclient(O) rtrsclient(O) rtrscore(O) rdmaucm rdmacm iwcm ibcm crc32generic rdmarxe ip6udptunnel udptunnel ibuverbs ibcore loop brd nullblk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? warn+0x79/0xc0 [ 920.624116] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.624356] ? reportbug+0xfb/0x150 [ 920.624594] ? handlebug+0x3c/0x60 [ 920.624796] ? excinvalidop+0x14/0x70 [ 920.624976] ? asmexcinvalidop+0x16/0x20 [ 920.625203] ? rxecompleter+0x989/0xcc0 [rdmarxe] [ 920.625474] ? rxecompleter+0x329/0xcc0 [rdmarxe] [ 920.625749] rxedotask+0x80/0x110 [rdmarxe] [ 920.626037] rxerequester+0x625/0xde0 [rdmarxe] [ 920.626310] ? rxecqpost+0xe2/0x180 [rdmarxe] [ 920.626583] ? docomplete+0x18d/0x220 [rdmarxe] [ 920.626812] ? rxecompleter+0x1a3/0xcc0 [rdmarxe] [ 920.627050] rxedotask+0x80/0x110 [rdmarxe] [ 920.627285] taskletactioncommon.constprop.0+0xa4/0x120 [ 920.627522] handlesoftirqs+0xc2/0x250 [ 920.627728] ? sortrange+0x20/0x20 [ 920.627942] runksoftirqd+0x1f/0x30 [ 920.628158] smpbootthreadfn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthreadcompleteandexit+0x20/0x20 [ 920.628709] retfromfork+0x1f/0x30 [ 920.628892] </TASK>

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

crypto: pcrypt - Call crypto layer directly when padatadoparallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATARESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In algtest(), a WARN is generated when pcryptaeaddecrypt() or pcryptaeadencrypt() returns -EAGAIN, the unnecessary panic will occur when paniconwarn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.

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

rtc: check if rtcreadtime was successful in rtctimerdowork()

If the rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.

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

ipvs: fix UB due to uninitialized stack access in ipvsprotocolinit()

Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ipvsprotocolinit(), triggering the following objtool warning during build time:

vmlinux.o: warning: objtool: ipvsprotocolinit() falls through to next function initstubkmodipvsrr935123ipvsrrinit6()

At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously.

Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ipvsprotocolinit() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIGFORTIFYSOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #5 section ".init.text" align 16 !kcfitype !29 { %1 = alloca [64 x i8], align 16 ...

14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23

20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ...

23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }

The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined:

%13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17

This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location:

define hidden i32 @ipvsprotocolinit() localunnamedaddr #0 section ".init.text" align 16 !kcfitype !11 { %1 = alloca [64 x i8], align 16 ...

12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }

In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator.

Zero the on-stack buffer to avoid this possible UB.

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

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

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

afs: Fix merge preference rule failure condition

syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released.

Fix this by store the error in ret and jump to done to clean up instead of returning directly.

[dh: Modified Lizhi Xu's original patch to make it honour the error code from afssplitstring()]

[1] WARNING: lock held when returning to user space! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted ------------------------------------------------ syz-executor133/5823 is leaving the kernel with locks still held! 1 lock held by syz-executor133/5823: #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: inodelock include/linux/fs.h:818 [inline] #0: ffff888071cffc00 (&sb->stype->imutexkey#9){++++}-{4:4}, at: afsprocaddrprefswrite+0x2bb/0x14e0 fs/afs/addrprefs.c:388

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

cachestat: fix page cache statistics permission checking

When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.

But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").

This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).

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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

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

can: isotp: sanitize CAN ID checks in isotpbind()

Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving.

Sanitize the SFF/EFF CAN ID values before performing the address checks.

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

efi: Do not import certificates from UEFI Secure Boot for T2 Macs

On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:

[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 eficrashgracefullyonpagefault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> pagefaultoops+0x4f/0x2c0 ? searchbpfextables+0x6b/0x80 ? searchmoduleextables+0x50/0x80 ? searchexceptiontables+0x5b/0x60 kernelmodefixuporoops+0x9e/0x110 badareanosemaphore+0x155/0x190 badareanosemaphore+0x16/0x20 dokernaddrfault+0x8c/0xa0 excpagefault+0xd8/0x180 asmexcpagefault+0x1e/0x30 (Removed some logs from here) ? eficall+0x28/0x30 ? switchmm+0x20/0x30 ? eficallrts+0x19a/0x8e0 ? processonework+0x222/0x3f0 ? workerthread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? processonework+0x3f0/0x3f0 ? setkthreadstruct+0x40/0x40 ? retfromfork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efirtswq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000

So we avoid reading these UEFI variables and thus prevent the crash.

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

powerpc/paprscm: don't requests stats with '0' sized stats buffer

Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being reported with vPMEM when paprscm probe is being called. The panic is of the form below and is observed only with following option disabled(profile) for the said LPAR 'Enable Performance Information Collection' in the HMC:

Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x0000001c Faulting instruction address: 0xc008000001b90844 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c008000001b90844] drcpmemquerystats+0x5c/0x270 [paprscm] LR [c008000001b92794] paprscmprobe+0x2ac/0x6ec [paprscm] Call Trace: 0xc00000000941bca0 (unreliable) paprscmprobe+0x2ac/0x6ec [paprscm] platformprobe+0x98/0x150 reallyprobe+0xfc/0x510 driverprobedevice+0x17c/0x230 <snip> ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception

On investigation looks like this panic was caused due to a 'statbuffer' of size==0 being provided to drcpmemquerystats() to fetch all performance stats-ids of an NVDIMM. However drcpmemquerystats() shouldn't have been called since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused due to missing check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents() which indicates that the NVDIMM doesn't support performance-stats.

Fix this by introducing the check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents().

[1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com