drivers/base/memory: set mem->altmap after successful device registration

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomicenable()

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

net: txgbe: fix RTNL assertion warning when remove module

For the copper NIC with external PHY, the driver called phylinkconnectphy() during probe and phylinkdisconnectphy() during remove. It caused an RTNL assertion warning in phylinkdisconnectphy() upon module remove.

To fix this, add rtnllock() and rtnlunlock() around the phylinkdisconnectphy() in remove function.

------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylinkdisconnectphy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylinkdisconnectphy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> txgberemovephy+0xbb/0xd0 [txgbe] txgberemove+0x4c/0xb0 [txgbe] pcideviceremove+0x41/0xb0 deviceremove+0x43/0x80 devicereleasedriverinternal+0x206/0x270 driverdetach+0x4a/0xa0 busremovedriver+0x83/0x120 driverunregister+0x2f/0x60 pciunregisterdriver+0x40/0x90 txgbedriverexit+0x10/0x850 [txgbe] dosysdeletemodule.isra.0+0x1c3/0x2f0 x64sysdeletemodule+0x12/0x20 x64syscall+0x20c3/0x2390 dosyscall64+0x11c/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dosyscall64+0x15a/0x1500 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dofault+0x312/0x580 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x9d5/0x1040 ? srsoaliasreturnthunk+0x5/0xfbef5 ? countmemcgevents+0x101/0x1d0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? handlemmfault+0x1e8/0x2f0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? douseraddrfault+0x2f8/0x820 ? srsoaliasreturnthunk+0x5/0xfbef5 ? irqentryexit+0xb2/0x600 ? srsoaliasreturnthunk+0x5/0xfbef5 ? excpagefault+0x92/0x1c0 entrySYSCALL64afterhwframe+0x76/0x7e

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

dmaengine: fsl-edma: don't explicitly disable clocks in .remove()

The clocks in fsledmaengine::muxclk are allocated and enabled with devmclkgetenabled(), which automatically cleans these resources up, but these clocks are also manually disabled in fsledmaremove(). This causes warnings on driver removal for each clock:

edmamodule already disabled WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clkcoredisable+0x198/0x1c8 [...] Call trace: clkcoredisable+0x198/0x1c8 (P) clkdisable+0x34/0x58 fsledmaremove+0x74/0xe8 [fsledma] [...] ---[ end trace 0000000000000000 ]--- edmamodule already unprepared WARNING: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clkcoreunprepare+0x1f8/0x220 [...] Call trace: clkcoreunprepare+0x1f8/0x220 (P) clkunprepare+0x34/0x58 fsledmaremove+0x7c/0xe8 [fsledma] [...] ---[ end trace 0000000000000000 ]---

Fix these warnings by removing the unnecessary fsldisableclocks() call in fsledmaremove().

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

ceph: fix numops off-by-one when crypto allocation fails

movedirtyfolioinpagearray() may fail if the file is encrypted, the dirty folio is not the first in the batch, and it fails to allocate a bounce buffer to hold the ciphertext. When that happens, cephprocessfoliobatch() simply redirties the folio and flushes the current batch -- it can retry that folio in a future batch.

However, if this failed folio is not contiguous with the last folio that did make it into the batch, then cephprocessfoliobatch() has already incremented cephwbc->numops; because it doesn't follow through and add the discontiguous folio to the array, cephsubmitwrite() -- which expects that cephwbc->numops accurately reflects the number of contiguous ranges (and therefore the required number of "write extent" ops) in the writeback -- will panic the kernel:

BUGON(cephwbc->opidx + 1 != req->rnumops);

This issue can be reproduced on affected kernels by writing to fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat pattern (total filesize should not matter) and gradually increasing the system's memory pressure until a bounce buffer allocation fails.

Fix this crash by decrementing cephwbc->numops back to the correct value when movedirtyfolioinpagearray() fails, but the folio already started counting a new (i.e. still-empty) extent.

The defect corrected by this patch has existed since 2022 (see first Fixes:), but another bug blocked multi-folio encrypted writeback until recently (see second Fixes:). The second commit made it into 6.18.16, 6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch therefore fixes a regression (panic) introduced by cac190c7674f.

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

x86/shstk: Prevent deadlock during shstk sigreturn

During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA.

Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock.

Fix this by not holding mmap lock during the read access to userspace.

Instead use mmaplockspeculate...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA.

These mmaplockspeculate...() helpers use mm::mmlockseq, which is only available when PERVMALOCK is configured. So make X86USERSHADOWSTACK depend on it. On x86, PERVMALOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist.

Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.

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

net/sched: taprio: fix NULL pointer dereference in class dump

When a TAPRIO child qdisc is deleted via RTMDELQDISC, tapriograft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTMGETTCLASS dump operations walk all classes via tapriowalk() and call tapriodumpclass(), which calls taprioleaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference.

The bug is reachable with namespace-scoped CAPNETADMIN on any kernel with CONFIGNETSCHTAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTMGETTCLASS dump itself requires no capability.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:tapriodumpclass (net/sched/schtaprio.c:2478) Call Trace: <TASK> tcfilltclass (net/sched/schapi.c:1966) qdiscclassdump (net/sched/schapi.c:2326) tapriowalk (net/sched/schtaprio.c:2514) tcdumptclassqdisc (net/sched/schapi.c:2352) tcdumptclassroot (net/sched/schapi.c:2370) tcdumptclass (net/sched/schapi.c:2431) rtnldumpit (net/core/rtnetlink.c:6864) netlinkdump (net/netlink/afnetlink.c:2325) rtnetlinkrcvmsg (net/core/rtnetlink.c:6959) netlinkrcvskb (net/netlink/afnetlink.c:2550) </TASK>

Fix this by substituting &noopqdisc when new is NULL in tapriograft(), a common pattern used by other qdiscs (e.g., multiqgraft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks.

Since the data-plane paths (taprioenqueue and tapriodequeuefromtxq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noopqdisc instead. Without this, packets would reach taprioenqueueone() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noopqdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics.

After this change old can be a valid qdisc, NULL, or &noopqdisc. Only call qdiscput(old) in the first case to avoid decreasing noopqdisc's refcount, which was never increased.

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

ceph: fix memory leaks in cephmdscbuildpath()

Add putname() calls to error code paths that did not free the "path" pointer obtained by getname(). If ownership of this pointer is not passed to the caller via pathinfo.path, the function must free it before returning.

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

x86/kexec: Disable KCOV instrumentation after loadsegments()

The loadsegments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIGKCOV is enabled, any subsequent instrumented C code call (e.g. nativegdtinvalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIGKEXEC and CONFIGKCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (sanitizercovtracepc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machinekexec64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIGKCOV is not supported there.

[ bp: Space out comment for better readability. ]

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

media: v4l2-async: Fix error handling on steps after finding a match

Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches.

Fix these specific issues:

- If v4l2asyncmatchnotify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2asyncmatchnotify().

- The async connection's sd field was only set after creating ancillary links in v4l2asyncmatchnotify(). It was however dereferenced in v4l2asyncunbindsubdevone(), which was called on error path of v4l2asyncmatchnotify() failure.

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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

xsk: validate MTU against usable frame size on bind

AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.

This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).

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

gve: fix incorrect buffer cleanup in gvetxcleanpendingpackets for QPL

In DQ-QPL mode, gvetxcleanpendingpackets() incorrectly uses the RDA buffer cleanup path. It iterates numbufs times and attempts to unmap entries in the dma array.

This leads to two issues: 1. The dma array shares storage with txqplbufids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations. 2. numbufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings (trace below is how we noticed this issue).

UBSAN: array-index-out-of-bounds in drivers/net/ethernet/drivers/net/ethernet/google/gve/gvetxdqo.c:178:5 index 18 is out of range for type 'dmaaddrt[18]' (aka 'unsigned long long[18]') Workqueue: gve gveservicetask [gve] Call Trace: <TASK> dumpstacklvl+0x33/0xa0 ubsanhandleoutofbounds+0xdc/0x110 gvetxstopringdqo+0x182/0x200 [gve] gveclose+0x1be/0x450 [gve] gvereset+0x99/0x120 [gve] gveservicetask+0x61/0x100 [gve] processscheduledworks+0x1e9/0x380

Fix this by properly checking for QPL mode and delegating to gvefreetxqplbufs() to reclaim the buffers.

audit: add fchmodat2() to change attributes class

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

ksmbd: fix infinite loop caused by nextsmb2rcvhdroff reset in error paths

The problem occurs when a signed request fails smb2 signature verification check. In processrequest(), if checksignreq() returns an error, setsmb2rspstatus(work, STATUSACCESSDENIED) is called. setsmb2rspstatus() set work->nextsmb2rcvhdroff as zero. By resetting nextsmb2rcvhdroff to zero, the pointer to the next command in the chain is lost. Consequently, ischainedsmb2message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing handleksmbdwork() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.

This patch fixes the issue by changing the return value from SERVERHANDLERCONTINUE to SERVERHANDLERABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.

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

platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names

The hp-bioscfg driver attempts to register kobjects with empty names when the HP BIOS returns attributes with empty name strings. This causes multiple kernel warnings:

kobject: (00000000135fb5e6): attempted to be registered with empty name! WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobjectaddinternal+0x2eb/0x310

Add validation in hpinitbiosbufferattribute() to check if the attribute name is empty after parsing it from the WMI buffer. If empty, log a debug message and skip registration of that attribute, allowing the module to continue processing other valid attributes.

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

interconnect: debugfs: initialize srcnode and dstnode to empty strings

The debugfscreatestr() API assumes that the string pointer is either NULL or points to valid kmalloc() memory. Leaving the pointer uninitialized can cause problems.

Initialize srcnode and dstnode to empty strings before creating the debugfs entries to guarantee that reads and writes are safe.

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

platform/x86: hp-bioscfg: Fix kernel panic in GETINSTANCEID macro

The GETINSTANCEID macro that caused a kernel panic when accessing sysfs attributes:

1. Off-by-one error: The loop condition used '<=' instead of '<', causing access beyond array bounds. Since array indices are 0-based and go from 0 to instancescount-1, the loop should use '<'.

2. Missing NULL check: The code dereferenced attrnamekobj->name without checking if attrnamekobj was NULL, causing a null pointer dereference in minlengthshow() and other attribute show functions.

The panic occurred when fwupd tried to read BIOS configuration attributes:

Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:minlengthshow+0xcf/0x1d0 [hpbioscfg]

Add a NULL check for attrnamekobj before dereferencing and corrects the loop boundary to match the pattern used elsewhere in the driver.

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

powerpc/kexec: Enable SMT before waking offline CPUs

If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:

kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core64.c:223 kexecpreparecpus+0x1b0/0x1bc [snip] NIP kexecpreparecpus+0x1b0/0x1bc LR kexecpreparecpus+0x1a0/0x1bc Call Trace: kexecpreparecpus+0x1a0/0x1bc (unreliable) defaultmachinekexec+0x160/0x19c machinekexec+0x80/0x88 kernelkexec+0xd0/0x118 dosysreboot+0x210/0x2c4 systemcallexception+0x124/0x320 systemcallvectoredcommon+0x15c/0x2ec

This occurs as addcpu() fails due to cpubootable() returning false for CPUs that fail the cpusmtthreadallowed() check or non primary threads if SMT is disabled.

Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.

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

drm/nouveau/nvif: Fix potential memory leak in nvifvmmctor().

When the nvifvmmtype is invalid, we will return error directly without freeing the args in nvifvmmctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.

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

spi: stm32: Check for cfg availability in stm32spiprobe

The stm32spiprobe function now includes a check to ensure that the pointer returned by ofdevicegetmatchdata is not NULL before accessing its members. This resolves a warning where a potential NULL pointer dereference could occur when accessing cfg->hasdevicemode.

Before accessing the 'hasdevicemode' member, we verify that 'cfg' is not NULL. If 'cfg' is NULL, an error message is logged.

This change ensures that the driver does not attempt to access configuration data if it is not available, thus preventing a potential system crash due to a NULL pointer dereference.

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

vfio/pds: Fix missing detachioas op

When CONFIGIOMMUFD is enabled and a device is bound to the pdsvfiopci driver, the following WARNON() trace is seen and probe fails:

WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfiomain.c:317 vfioregisterdev+0x130/0x140 [vfio] <...> pdsvfiopci 0000:08:00.1: probe with driver pdsvfiopci failed with error -22

This is because the driver's vfiodeviceops.detachioas isn't set.

Fix this by using the generic vfioiommufdphysicaldetachioas function.

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

tracing/osnoise: Fix crash in timerlatdumpstack()

We have observed kernel panics when using timerlat with stack saving, with the following dmesg output:

memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/stringhelpers.c:1032 fortifyreport+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x8664 #1 PREEMPT(lazy) Call Trace: <TASK> ? tracebufferlockreserve+0x2a/0x60 fortifypanic+0xd/0xf timerlatdumpstack.cold+0xd/0xd timerlatdumpstack.part.0+0x47/0x80 timerlatfdread+0x36d/0x390 vfsread+0xe2/0x390 ? syscallexittousermode+0x1d5/0x210 ksysread+0x73/0xe0 dosyscall64+0x7b/0x160 ? excpagefault+0x7e/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e

timerlatdumpstack() constructs the ftrace stack entry like this:

struct stackentry entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nrentries;

Since commit e7186af7fb26 ("tracing: Add back FORTIFYSOURCE logic to kernelstack event structure"), struct stackentry marks its caller field with countedby(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow.

Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to ftracetracestack().

fpga: fix potential null pointer deref in fpgamgrtestimgloadsgt()

drm/amdgpu: csa unmap use uninterruptible lock

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

book3s64/radix : Align section vmemmap start address to PAGESIZE

A vmemmap altmap is a device-provided region used to provide backing storage for struct pages. For each namespace, the altmap should belong to that same namespace. If the namespaces are created unaligned, there is a chance that the section vmemmap start address could also be unaligned. If the section vmemmap start address is unaligned, the altmap page allocated from the current namespace might be used by the previous namespace also. During the free operation, since the altmap is shared between two namespaces, the previous namespace may detect that the page does not belong to its altmap and incorrectly assume that the page is a normal page. It then attempts to free the normal page, which leads to a kernel crash.

Kernel attempted to read user page (18) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000018 Faulting instruction address: 0xc000000000530c7c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Radix SMP NRCPUS=2048 NUMA pSeries CPU: 32 PID: 2104 Comm: ndctl Kdump: loaded Tainted: G W NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe REGS: c000000015e57040 TRAP: 0300 Tainted: G W MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 84482404 CFAR: c000000000530dfc DAR: 0000000000000018 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 GPR04: 0000000000000000 0000000000000007 0000000000000001 000000000000001f GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 GPR16: c00c000101008000 0000000000000001 0000000000000000 c000000125b20f00 GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000004040201 0000000000000001 0000000000000000 c00c000101008040 NIP [c000000000530c7c] getpfnblockflagsmask+0x7c/0xd0 LR [c000000000530e00] freeunrefpageprepare+0x130/0x4f0 Call Trace: freeunrefpage+0x50/0x1e0 freereservedpage+0x40/0x68 freevmemmappages+0x98/0xe0 removeptetable+0x164/0x1e8 removepmdtable+0x204/0x2c8 removepudtable+0x1c4/0x288 removepagetable+0x1c8/0x310 vmemmapfree+0x24/0x50 sectiondeactivate+0x28c/0x2a0 removepages+0x84/0x110 archremovememory+0x38/0x60 memunmappages+0x18c/0x3d0 devmactionrelease+0x30/0x50 releasenodes+0x68/0x140 devresreleasegroup+0x100/0x190 daxpmemcompatrelease+0x44/0x80 [daxpmemcompat] deviceforeachchild+0x8c/0x100 [daxpmemcompatremove+0x2c/0x50 [daxpmemcompat] nvdimmbusremove+0x78/0x140 [libnvdimm] deviceremove+0x70/0xd0

Another issue is that if there is no altmap, a PMD-sized vmemmap page will be allocated from RAM, regardless of the alignment of the section start address. If the section start address is not aligned to the PMD size, a VMBUGON will be triggered when setting the PMD-sized page to page table.

In this patch, we are aligning the section vmemmap start address to PAGESIZE. After alignment, the start address will not be part of the current namespace, and a normal page will be allocated for the vmemmap mapping of the current section. For the remaining sections, altmaps will be allocated. During the free operation, the normal page will be correctly freed.

In the same way, a PMDSIZE vmemmap page will be allocated only if the section start address is PMDSIZE-aligned; otherwise, it will fall back to a PAGE-sized vmemmap allocation.

Without this patch ================== NS1 start NS2 start | NS1 | NS2 | --------------------------------------------------------- | Altmap| Altmap | .....|Altmap| Altmap | ........... | NS1 | NS1 ---truncated---

ASoC: Intel: avs: Fix null-ptr-deref in avscomponentprobe()

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

drm/mediatek: dp: drmerr => deverr in HPD path to avoid NULL ptr

The function mtkdpwaithpdasserted() may be called before the mtkdp->drmdev pointer is assigned in mtkdpbridgeattach(). Specifically it can be called via this callpath: - mtkedpwaithpdasserted - [panel probe] - dpauxepprobe

Using "drm" level prints anywhere in this callpath causes a NULL pointer dereference. Change the error message directly in mtkdpwaithpdasserted() to deverr() to avoid this. Also change the error messages in mtkdpparsecapabilities(), which is called by mtkdpwaithpdasserted().

While touching these prints, also add the error code to them to make future debugging easier.

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

vmxnet3: unregister xdp rxq info in the reset path

vmxnet3 does not unregister xdp rxq info in the vmxnet3resetwork() code path as vmxnet3rqdestroy() is not invoked in this code path. So, we get below message with a backtrace.

Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 xdprxqinforeg+0x93/0xf0

This patch fixes the problem by moving the unregister code of XDP from vmxnet3rqdestroy() to vmxnet3rqcleanup().