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

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.

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

iouring/poll: fix signed comparison in iopollgetownership()

iopollgetownership() uses a signed comparison to check whether pollrefs has reached the threshold for the slowpath:

if (unlikely(atomicread(&req->pollrefs) >= IOPOLLREFBIAS))

atomicread() returns int (signed). When IOPOLLCANCELFLAG (BIT(31)) is set in pollrefs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken.

Fix this by casting the atomicread() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.

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

iouring/eventfd: ensure ioeventfdsignal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

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

smb: client: fix OOB reads parsing symlink error response

When a CREATE returns STATUSSTOPPEDONSYMLINK, smb2checkmessage() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server.

symlinkdata() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits.

smb2parsesymlinkresponse() then bounds-checks the substitute name using SMB2SYMLINKSTRUCTSIZE as the offset of PathBuffer from iovbase. That value is computed as sizeof(smb2errrsp) + sizeof(smb2symlinkerrrsp), which is correct only when ErrorContextCount == 0.

With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iovlen. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2).

Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset.

Because suboffs and sublen are 16bits, the pointer math will not overflow here with the new greater-than.

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

pmdomain: imx8mp-blk-ctrl: Keep the NOCHDCP clock enabled

Keep the NOCHDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.

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

Bluetooth: MGMT: validate mesh send advertising payload length

meshsend() currently bounds MGMTOPMESHSEND by total command length, but it never verifies that the bytes supplied for the flexible advdata[] array actually match the embedded advdatalen field. MGMTMESHSENDSIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer.

Keep rejecting zero-length and oversized advertising payloads, but validate advdatalen explicitly and require the command length to exactly match the flexible array size before queueing the request.

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

KVM: x86: Ignore -EBUSY when checking nested events from vcpublock()

Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVMEXITUNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as something has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects.

As explained in the Fixes commits, it should be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MPSTATE and/or injected events, and thus put the vCPU into what should be an impossible state.

Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where KVM would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running.

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

dm: clear cloned request bio pointer when last clone bio completes

Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios.

One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blkcompleterequest(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blkrqunprepclone().

The resulting double-free path looks like:

nvmepcicompletebatch() nvmecompletebatch() blkmqendrequestbatch() blkcompleterequest() // called on a DM clone request bioendio() // first free of all clone bios ... rq->endio() // endclonerequest() dmcompleterequest(tio->orig) dmsoftirqdone() dmdone() dmendrequest() blkrqunprepclone() // second free of clone bios

Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.

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

wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwlmvmndmatchinfohandler()

The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

NFSD: Fix SECINFONONAME decode error cleanup

nfsd4decodesecinfononame() currently initializes sinexp after decoding sinstyle. If the XDR stream is truncated, the decoder returns nfserrbadxdr before sinexp is initialized.

Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFONONAME decode can therefore leave sinexp holding stale union contents from a previous operation.

The error response path still invokes nfsd4secinfononamerelease(), which calls expput() on a non-NULL sinexp.

Initialize sinexp before the first failable decode step, matching nfsd4decodesecinfo().

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

wifi: mac80211: prohibit deactivating all links

In the internal API this calls this is a WARNON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.

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

x86/amdnb: Use rdmsrsafe() in amdgetmmconfigrange()

Xen doesn't offer MSRFAM10HMMIOCONFBASE to all guests. This results in the following warning:

unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xendoreadmsr+0x7f/0xa0) Call Trace: xenreadmsr+0x1e/0x30 amdgetmmconfigrange+0x2b/0x80 quirkamdmmconfigarea+0x28/0x100 pnpfixupdevice+0x39/0x50 pnpadddevice+0xf/0x150 pnpadddevice+0x3d/0x100 pnpacpiadddevicehandler+0x1f9/0x280 acpinsgetdevicecallback+0x104/0x1c0 acpinswalknamespace+0x1d0/0x260 acpigetdevices+0x8a/0xb0 pnpacpiinit+0x50/0x80 dooneinitcall+0x46/0x2e0 kernelinitfreeable+0x1da/0x2f0 kernelinit+0x16/0x1b0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30

based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.

drm/amdkfd: Fix double release compute pasid

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

scsi: mpi3mr: Fix NULL pointer dereference in mpi3mrsasportadd()

sasportallocnum() can return NULL on memory allocation failure. The return value is passed directly to sasportadd() without a NULL check, which causes a NULL pointer dereference.

Additionally, if sasportadd() fails, the allocated port is not freed before jumping to outfail, leaking the sasport structure. Call sasportfree() to properly release it.

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

scsi: mpi3mr: Fix target device refcount leak in mpi3mrsasportadd()

mpi3mrgettgtdevbyaddr() increments the target device kref when it returns a device. If a subsequent error triggers a goto outfail after the tgtdev reference is acquired, the reference is never released because the outfail path does not call mpi3mrtgtdevput(). This prevents the target device structure from ever being freed.

Add a tgtdev put in the outfail path, guarded by a NULL check since tgtdev is only acquired for SASENDDEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL.

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

pppasync: drop the errored frame instead of resetting its headroom

pppreceivenonmpframe() prepends a two-byte direction tag before running the pass/active BPF filters:

(be16 )skbpush(skb, 2) = htons(PPPFILTERINBOUNDTAG);

Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in pppasync's processinputpacket() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from devallocskb() carries NETSKBPAD:

err: if (skb) { / make skb appear as freshly allocated / skbtrim(skb, 0); skbreserve(skb, - skbheadroom(skb)); }

ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head:

skbuff: skbunderpanic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x13e/0x230 Call Trace: skbpush+0xbd/0x100 pppreceivenonmpframe+0x48a/0x1d10 pppinput+0x4e9/0x2f80 pppasyncprocess+0x2a/0xe0 taskletactioncommon+0x20f/0x8a0 handlesoftirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt

Zeroing the headroom violates the NETSKBPAD guarantee that devallocskb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled pppdecompressframe() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason.

Rather than restore the headroom, drop the errored frame - as pppsynctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read.

The original V1 of this patch made room in pppreceivenonmpframe() with skbcowhead(); Eric pointed out that fixing the root cause in the transport is the right approach.

Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.

EDAC/devicesysfs: Use kstrtouint() for pollmsec to prevent truncation

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

wifi: mt76: mt7921: validate CLC firmware records

The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying.

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

nvme-rdma: fix -EIO cleanup order in queuerq

On -EIO, the RDMA queuerq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete.

Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.

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

smb/client: fix stale page cache in insert/collapse range

smb3insertrange() and smb3collapserange() use truncatepagecacherange() to invalidate the affected page cache. However, if off or oldeof is not page-aligned, the boundary pages are only partially zeroed and remain uptodate. As a result, the client may return stale data after a successful insert/collapse range operation.

For example, with 4K pages:

page 0 page 1 page 2 0------4K 4K------8K 8K------12K ^ ^ off=2K oldeof=10K

Page 1 is removed from the page cache, while the boundary pages are only partially zeroed. After COPYCHUNK moves the data on the server, these cached pages may still return stale data.

This can be reproduced on a CIFS mount:

bash -c ' FILE=/mnt/scratch/repro

# Use a 6 KiB file so EOF is not page-aligned. dd if=/dev/urandom of=/tmp/src bs=1K count=6 status=none

# Expected: a 4 KiB hole followed by the original data. rm -f /tmp/expected truncate -s 4K /tmp/expected cat /tmp/src >> /tmp/expected

cp /tmp/src "$FILE"

# Prime the page cache before moving data on the server. cat "$FILE" > /dev/null

fallocate --insert-range -o 0 -l 4K "$FILE"

if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi '

Fix this by writing back dirty data and discarding the page cache from the start of the page containing off to EOF before moving data on the server.

cgroup/rstat: validate cpu before cssrstatcpu() access

Bluetooth: virtiobt: validate rx pkttype header length

clk: microchip: mpfs-ccc: fix out of bounds access during output registration

Bluetooth: virtiobt: clamp rx length before skbput

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

ASoC: SOF: Don't allow pointer operations on unconfigured streams

When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not

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

spi: microchip-core-qspi: control built-in cs manually

The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO.

This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled.

Modify the driver so that it controls chip select directly, retaining the behaviour for memops of setting the chip select active for the entire duration of the transfer in the execop callback. For regular transfers, implement the setcs callback for the core to use.

As part of this, the existing setup callback, mchpcoreqspisetupop(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

arm64: Set nocfi on swsusparchresume()

A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusparchsuspendexit() is marked with SYMCODE() and does not have a CFI hash, but swsusparchresume() will attempt to verify the CFI hash when calling a copy of swsusparchsuspendexit().

Given that there's an existing requirement that the entrypoint to swsusparchsuspendexit() is the first byte of the .hibernateexit.text section, we cannot fix this by marking swsusparchsuspendexit() with SYMFUNC(). The simplest fix for now is to disable the CFI check in swsusparchresume().

Mark swsusparchresume() as nocfi to disable the CFI check.

[1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but activemm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusparchresume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] hibernationrestore+0x158/0x18c [ 22.991934][ T1] loadimageandrestore+0xb0/0xec [ 22.991934][ T1] softwareresume+0xf4/0x19c [ 22.991934][ T1] softwareresumeinitcall+0x34/0x78 [ 22.991934][ T1] dooneinitcall+0xe8/0x370 [ 22.991934][ T1] doinitcalllevel+0xc8/0x19c [ 22.991934][ T1] doinitcalls+0x70/0xc0 [ 22.991934][ T1] dobasicsetup+0x1c/0x28 [ 22.991934][ T1] kernelinitfreeable+0xe0/0x148 [ 22.991934][ T1] kernelinit+0x20/0x1a8 [ 22.991934][ T1] retfromfork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)

[catalin.marinas@arm.com: commit log updated by Mark Rutland]

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

ASoC: tlv320adcx140: fix null pointer

The "sndsoccomponent" in "adcx140priv" was only used once but never set. It was only used for reaching "dev" which is already present in "adcx140priv".

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

drm/display/dpmst: Add protection against 0 vcpi

When releasing a timeslot there is a slight chance we may end up with the wrong payload mask due to overflow if the delayeddestroywork ends up coming into play after a DP 2.1 monitor gets disconnected which causes vcpi to become 0 then we try to make the payload = ~BIT(vcpi - 1) which is a negative shift. VCPI id should never really be 0 hence skip changing the payload mask if VCPI is 0.

Otherwise it leads to <7> [515.287237] xe 0000:03:00.0: [drm:drmdpmstgetportmalloc [drmdisplayhelper]] port ffff888126ce9000 (3) <4> [515.287267] -----------[ cut here ]----------- <3> [515.287268] UBSAN: shift-out-of-bounds in ../drivers/gpu/drm/display/drmdpmsttopology.c:4575:36 <3> [515.287271] shift exponent -1 is negative <4> [515.287275] CPU: 7 UID: 0 PID: 3108 Comm: kworker/u64:33 Tainted: G S U 6.17.0-rc6-lgci-xe-xe-3795-3e79699fa1b216e92+ #1 PREEMPT(voluntary) <4> [515.287279] Tainted: [S]=CPUOUTOFSPEC, [U]=USER <4> [515.287279] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 1645 03/15/2024 <4> [515.287281] Workqueue: drmdpmstwq drmdpdelayeddestroywork [drmdisplayhelper] <4> [515.287303] Call Trace: <4> [515.287304] <TASK> <4> [515.287306] dumpstacklvl+0xc1/0xf0 <4> [515.287313] dumpstack+0x10/0x20 <4> [515.287316] ubsanhandleshiftoutofbounds+0x133/0x2e0 <4> [515.287324] ? drmatomicgetprivateobjstate+0x186/0x1d0 <4> [515.287333] drmdpatomicreleasetimeslots.cold+0x17/0x3d [drmdisplayhelper] <4> [515.287355] mstconnectoratomiccheck+0x159/0x180 [xe] <4> [515.287546] drmatomichelpercheckmodeset+0x4d9/0xfa0 <4> [515.287550] ? wwmutexlock.constprop.0+0x6f/0x1a60 <4> [515.287562] intelatomiccheck+0x119/0x2b80 [xe] <4> [515.287740] ? findheldlock+0x31/0x90 <4> [515.287747] ? lockrelease+0xce/0x2a0 <4> [515.287754] drmatomiccheckonly+0x6a2/0xb40 <4> [515.287758] ? drmatomicaddaffectedconnectors+0x12b/0x140 <4> [515.287765] drmatomiccommit+0x6e/0xf0 <4> [515.287766] ? pfxdrmprintfninfo+0x10/0x10 <4> [515.287774] drmclientmodesetcommitatomic+0x25c/0x2b0 <4> [515.287794] drmclientmodesetcommitlocked+0x60/0x1b0 <4> [515.287795] ? mutexlocknested+0x1b/0x30 <4> [515.287801] drmclientmodesetcommit+0x26/0x50 <4> [515.287804] drmfbhelperrestorefbdevmodeunlocked+0xdc/0x110 <4> [515.287810] drmfbhelperhotplugevent+0x120/0x140 <4> [515.287814] drmfbdevclienthotplug+0x28/0xd0 <4> [515.287819] drmclienthotplug+0x6c/0xf0 <4> [515.287824] drmclientdevhotplug+0x9e/0xd0 <4> [515.287829] drmkmshelperhotplugevent+0x1a/0x30 <4> [515.287834] drmdpdelayeddestroywork+0x3df/0x410 [drmdisplayhelper] <4> [515.287861] processonework+0x22b/0x6f0 <4> [515.287874] workerthread+0x1e8/0x3d0 <4> [515.287879] ? pfxworkerthread+0x10/0x10 <4> [515.287882] kthread+0x11c/0x250 <4> [515.287886] ? pfxkthread+0x10/0x10 <4> [515.287890] retfromfork+0x2d7/0x310 <4> [515.287894] ? pfxkthread+0x10/0x10 <4> [515.287897] retfromforkasm+0x1a/0x30