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

iouring: prevent opcode speculation

sqe->opcode is used for different tables, make sure we santitise it against speculations.

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

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

tls: Use skdstget() and dstdevrcu() in getnetdevforsock().

getnetdevforsock() is called during setsockopt(), so not under RCU.

Using skdstget(sk)->dev could trigger UAF.

Let's use skdstget() and dstdevrcu().

Note that the only ->ndoskgetlowerdev() user is bondskgetlowerdev(), which uses RCU.

fs/buffer: fix use-after-free when call bhread() helper

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

netfilter: nfreject: don't leak dst refcount for loopback packets

recent patches to add a WARN() when replacing skb dst entry found an old bug:

WARNING: include/linux/skbuff.h:1165 skbdstcheckunset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skbdstset include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nfrejectfillskbdst+0x2a4/0x330 net/ipv4/netfilter/nfrejectipv4.c:234 [..] Call Trace: nfsendunreach+0x17b/0x6e0 net/ipv4/netfilter/nfrejectipv4.c:325 nftrejectineteval+0x4bc/0x690 net/netfilter/nftrejectinet.c:27 exprcallopseval net/netfilter/nftablescore.c:237 [inline] ..

This is because blamed commit forgot about loopback packets. Such packets already have a dstentry attached, even at PREROUTING stage.

Instead of checking hook just check if the skb already has a route attached to it.

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

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

eventpoll: Fix semi-unbounded recursion

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

NFSD: fix race between nfsd registration and exportsproc

As of now nfsd calls createprocexportsentry() at start of initnfsd and cleanup by removeprocentry() at last of exitnfsd.

Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd

for 5.4 kernel ARM64:

CPU 1: el1irq+0xbc/0x180 archcountergetcntvct+0x14/0x18 runningclock+0xc/0x18 preemptcountadd+0x88/0x110 prepnewpage+0xb0/0x220 getpagefromfreelist+0x2d8/0x1778 allocpagesnodemask+0x15c/0xef0 vmallocnoderange+0x28c/0x478 vmallocnodeflagscaller+0x8c/0xb0 kvmallocnode+0x88/0xe0 nfsdinitnet+0x6c/0x108 [nfsd] opsinit+0x44/0x170 registerpernetoperations+0x114/0x270 registerpernetsubsys+0x34/0x50 initnfsd+0xa8/0x718 [nfsd] dooneinitcall+0x54/0x2e0

CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010

PC is at : exportsnetopen+0x50/0x68 [nfsd]

Call trace: exportsnetopen+0x50/0x68 [nfsd] exportsprocopen+0x2c/0x38 [nfsd] procregopen+0xb8/0x198 dodentryopen+0x1c4/0x418 vfsopen+0x38/0x48 pathopenat+0x28c/0xf18 dofilpopen+0x70/0xe8 dosysopen+0x154/0x248

Sometimes it crashes at exportsnetopen() and sometimes cacheseqnextrcu().

and same is happening on latest 6.14 kernel as well:

[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cacheseqnextrcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cacheseqnextrcu+0x78/0xa4 (P) [ 285.470488] seqread+0xe0/0x11c [ 285.470675] procregread+0x9c/0xf0 [ 285.470874] vfsread+0xc4/0x2fc [ 285.471057] ksysread+0x6c/0xf4 [ 285.471231] arm64sysread+0x1c/0x28 [ 285.471428] invokesyscall+0x44/0x100 [ 285.471633] el0svccommon.constprop.0+0x40/0xe0 [ 285.471870] doel0svccompat+0x1c/0x34 [ 285.472073] el0svccompat+0x2c/0x80 [ 285.472265] el0t32synchandler+0x90/0x140 [ 285.472473] el0t32sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---

It reproduced simply with below script: while [ 1 ] do /exportfs -r done &

while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &

So exporting interfaces to user space shall be done at last and cleanup at first place.

With change there is no Kernel OOPs.

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

netfilter: nftsetpipapo: clamp maximum map bucket size to INTMAX

Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset.

Similar to:

b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INTMAX")

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

net: clear the dst when changing skb protocol

A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6:

BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6rcvcore (net/ipv6/ip6input.c:190:20) ipv6rcv (net/ipv6/ip6input.c:306:8) processbacklog (net/core/dev.c:6186:4) napipoll (net/core/dev.c:6906:9) netrxaction (net/core/dev.c:7028:13) dosoftirq (kernel/softirq.c:462:3) netifrx (net/core/dev.c:5326:3) devloopbackxmit (net/core/dev.c:4015:2) ipmcfinishoutput (net/ipv4/ipoutput.c:363:8) NFHOOK (./include/linux/netfilter.h:314:9) ipmcoutput (net/ipv4/ipoutput.c:400:5) dstoutput (./include/net/dst.h:459:9) iplocalout (net/ipv4/ipoutput.c:130:9) ipsendskb (net/ipv4/ipoutput.c:1496:8) udpsendskb (net/ipv4/udp.c:1040:8) udpsendmsg (net/ipv4/udp.c:1328:10)

The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netifrx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6rcvcore which tries to use skbdst(). But the dst is still an IPv4 one left after IPv4 mcast output.

Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.

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

netfilter: nftsetpipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following multiplication does not overflow:

- desc->fieldlen[] maximum value is U8MAX multiplied by NFTPIPAPOGROUPSPERBYTE(f) that can be 2, worst case. - NFTPIPAPOBUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(f->lt), lt in struct nftpipapofield.

Then, use checkmuloverflow() to multiply by bucket size and then use checkaddoverflow() to the alignment for avx2 (if needed). Finally, add ltsizecheckoverflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFPKERNEL to GFPKERNELACCOUNT for consistency, in pipaporesize().

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

net: stmmac: make sure that ptprate is not 0 before configuring EST

If the ptprate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0.

Prevent this division by 0 by adding the corresponding check and error code.

ext4: fix out-of-bound read in ext4xattrinodedecrefall()

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

net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105tabledeleteentry()

There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds.

The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.

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

x86/mm/pat: Fix VMPAT handling when fork() fails in copypagerange()

If trackpfncopy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables.

Consequently untrackpfn() will see VMPAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied.

The easiest fix would be to simply clear the VMPAT flag of the dst VMA if trackpfncopy() fails. However, the whole thing is about "simply" clearing the VMPAT flag is shaky as well: if we passed trackpfncopy() and performed a reservation, but copying the page tables fails, we'll simply clear the VMPAT flag, not properly undoing the reservation ... which is also wrong.

So let's fix it properly: set the VMPAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VMPAT flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will get removed later, after copypagerange() succeeded; as VMPAT is not set then, we won't try cleaning VMPAT up once more and untrackpfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/patfork.c

WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 getpatinfo+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:getpatinfo+0xf6/0x110 ... Call Trace: <TASK> ... untrackpfn+0x52/0x110 unmapsinglevma+0xa6/0xe0 unmapvmas+0x105/0x1f0 exitmmap+0xf6/0x460 mmput+0x4b/0x120 copyprocess+0x1bf6/0x2aa0 kernelclone+0xab/0x440 dosysclone+0x66/0x90 dosyscall64+0x95/0x180

Likely this case was missed in:

d155df53f310 ("x86/mm/pat: clear VMPAT if copyp4drange failed")

... and instead of undoing the reservation we simply cleared the VMPAT flag.

Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like trackpfnremap/untrackpfn separately.

drm/amdgpu: avoid buffer overflow attach in smusyssetpptable()

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

wifi: iwlwifi: mvm: ensure offloading TID queue exists

The Linux kernel CVE team has assigned CVE-2024-27056 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050115-CVE-2024-27056-98c0@gregkh/T

Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete

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

rxrpc: Fix handling of received connection abort

Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.

Also add some tracing for the logging of connection aborts.

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

net: ks8851: Handle softirqs at the end of IRQ thread to fix hang

The ks8851irq() thread may call ks8851rxpkts() in case there are any packets in the MAC FIFO, which calls netifrx(). This netifrx() implementation is guarded by localbhdisable() and localbhenable(). The localbhenable() may call dosoftirq() to run softirqs in case any are pending. One of the softirqs is netrxaction, which ultimately reaches the driver .startxmit callback. If that happens, the system hangs. The entire call chain is below:

ks8851startxmitpar from netdevstartxmit netdevstartxmit from devhardstartxmit devhardstartxmit from schdirectxmit schdirectxmit from devqueuexmit devqueuexmit from neighupdate neighupdate from neighupdate neighupdate from arpprocess.constprop.0 arpprocess.constprop.0 from netifreceiveskbonecore netifreceiveskbonecore from processbacklog processbacklog from napipoll.constprop.0 napipoll.constprop.0 from netrxaction netrxaction from dosoftirq dosoftirq from callwithstack callwithstack from dosoftirq dosoftirq from localbhenableip localbhenableip from netifrx netifrx from ks8851irq ks8851irq from irqthreadfn irqthreadfn from irqthread irqthread from kthread kthread from retfromfork

The hang happens because ks8851irq() first locks a spinlock in ks8851par.c ks8851lockpar() spinlockirqsave(&ksp->lock, ...) and with that spinlock locked, calls netifrx(). Once the execution reaches ks8851startxmitpar(), it calls ks8851lockpar() again which attempts to claim the already locked spinlock again, and the hang happens.

Move the dosoftirq() call outside of the spinlock protected section of ks8851irq() by disabling BHs around the entire spinlock protected section of ks8851irq() handler. Place localbhenable() outside of the spinlock protected section, so that it can trigger dosoftirq() without the ks8851par.c ks8851lockpar() spinlock being held, and safely call ks8851startxmitpar() without attempting to lock the already locked spinlock.

Since ks8851irq() is protected by localbhdisable()/localbhenable() now, replace netifrx() with netifrx() which is not duplicating the localbhdisable()/localbhenable() calls.

drm/panfrost: Fix the error path in panfrostmmumapfaultaddr()

drm/vc4: don't check if plane->state->fb == state->fb

ax25: fix use-after-free bugs caused by ax25dsdeltimer

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

smb: client: fix potential UAF in cifsstatsprocwrite()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

scsi: mpi3mr: Bad drive in topology results kernel crash

When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the driver frees up the memory allocated for an internal HBA port data structure. However, in some places, the reference to the freed memory is not cleared. When the firmware sends the Device Info change event for the same device again, the freed memory is accessed and that leads to memory corruption and OS crash.

dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup

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

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.

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

sched/rt: Fix race in pushrttask

Overview ======== When a CPU chooses to call pushrttask and picks a task to push to another CPU's runqueue then it will call findlocklowestrq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (onrq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list.

Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself.

Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUGON(idx >= MAXRTPRIO) Call Trace: ? diebody+0x1a/0x60 ? die+0x2a/0x50 ? dotrap+0x85/0x100 ? picknexttaskrt+0x6e/0x1d0 ? doerrortrap+0x64/0xa0 ? picknexttaskrt+0x6e/0x1d0 ? excinvalidop+0x4c/0x60 ? picknexttaskrt+0x6e/0x1d0 ? asmexcinvalidop+0x12/0x20 ? picknexttaskrt+0x6e/0x1d0 schedule+0x5cb/0x790 ? updatetstimestats+0x55/0x70 scheduleidle+0x1e/0x40 doidle+0x15e/0x200 cpustartupentry+0x19/0x20 startsecondary+0x117/0x160 secondarystartup64noverify+0xb0/0xbb

-> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? diebody+0x1a/0x60 ? nocontext+0x183/0x350 ? warn+0x8a/0xe0 ? excpagefault+0x3d6/0x520 ? asmexcpagefault+0x1e/0x30 ? picknexttaskrt+0xb5/0x1d0 ? picknexttaskrt+0x8c/0x1d0 schedule+0x583/0x7e0 ? updatetstimestats+0x55/0x70 scheduleidle+0x1e/0x40 doidle+0x15e/0x200 cpustartupentry+0x19/0x20 startsecondary+0x117/0x160 secondarystartup64noverify+0xb0/0xbb

-> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUGON(rq->cpu != taskcpu(p))

-> kernel BUG at kernel/sched/rt.c:1055! BUGON(!rq->nrrunning) Call Trace: ? diebody+0x1a/0x60 ? die+0x2a/0x50 ? dotrap+0x85/0x100 ? dequeuetoprtrq+0xa2/0xb0 ? doerrortrap+0x64/0xa0 ? dequeuetoprtrq+0xa2/0xb0 ? excinvalidop+0x4c/0x60 ? dequeuetoprtrq+0xa2/0xb0 ? asmexcinvalidop+0x12/0x20 ? dequeuetoprtrq+0xa2/0xb0 dequeuertentity+0x1f/0x70 dequeuetaskrt+0x2d/0x70 schedule+0x1a8/0x7e0 ? blkfinishplug+0x25/0x40 schedule+0x3c/0xb0 futexwaitqueueme+0xb6/0x120 futexwait+0xd9/0x240 dofutex+0x344/0xa90 ? getmmexefile+0x30/0x60 ? auditexecompare+0x58/0x70 ? auditfilterrules.constprop.26+0x65e/0x1220 x64sysfutex+0x148/0x1f0 dosyscall64+0x30/0x80 entrySYSCALL64afterhwframe+0x62/0xc7

-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? diebody+0x1a/0x60 ? nocontext+0x183/0x350 ? spuriouskernelfault+0x171/0x1c0 ? excpagefault+0x3b6/0x520 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? asmexcpagefault+0x1e/0x30 ? condresched+0x15/0x30 ? futexwaitqueueme+0xc8/0x120 ? futexwait+0xd9/0x240 ? trytowakeup+0x1b8/0x490 ? futexwake+0x78/0x160 ? dofutex+0xcd/0xa90 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? plistdel+0x6a/0xd0 ? plistchecklist+0x15/0x40 ? plistchecklist+0x2e/0x40 ? dequeuepushabletask+0x20/0x70 ? schedule+0x382/0x7e0 ? asmsysvecreschedulei ---truncated---