firmware: stratix10-svc: fix memory leaks and list corruption bugs

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

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

ice: fix double-free of txbuf skb

If icetso() or icetxcsum() fail, the error path in icexmitframering() frees the skb, but the 'first' txbuf still points to it and is marked as valid (ICETXBUFSKB). 'nexttouse' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the txbuf gets overwritten. But if there is no next packet and the interface is brought down instead, icecleantxring() -> iceunmapandfreetxbuf() will find the txbuf and free the skb for the second time.

The fix is to reset the txbuf type to ICETXBUFEMPTY in the error path, so that iceunmapandfreetxbuf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path.

The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch.

I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN.

I looked for similar bugs in related Intel drivers and did not find any.

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

Bluetooth: l2cap: Add missing chan lock in l2capecredreconfrsp

l2capecredreconfrsp() calls l2capchandel() without holding l2capchanlock(). Every other l2capchandel() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.

Add l2capchanhold() and l2capchanlock() before l2capchandel(), and l2capchanunlock() and l2capchanput() after, matching the pattern used in l2capecredconnrsp() and l2capconndel().

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

crypto: ccp - copy IV using skcipher ivsize

AFALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use cryptoskcipherivsize() to copy only the algorithm's IV length.

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

vfio/pci: Clean up DMABUFs before disabling function

On device shutdown, make vfiopcicoreclosedevice() call vfiopcidmabufcleanup() before the function is disabled via vfiopcicoredisable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible.

This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver.

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

iouring/io-wq: re-check IOWQBITEXIT for each linked work item

commit 10dc95939817 ("iouring/io-wq: check IOWQBITEXIT inside work run loop") fixed the obvious case where ioworkerhandlework() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.

ioworkerhandlework() now re-checks IOWQBITEXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If iowqexitstart() sets IOWQBITEXIT after the first linked item has started, the remaining linked items can still reuse stale dokill = false, skip IOWQWORKCANCEL, and continue running after exit has begun.

Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.

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

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

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

mailbox: add sanity check for channel array

Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.

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

nbd: restrict sockets to TCP and UDP

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup") made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.

cgroup: split cgroupdestroywq into 3 workqueues

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

fs: Prevent file descriptor table allocations exceeding INTMAX

bpf: Forget ranges when refining tnum after JSET

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

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.

bpf: avoid holding freezemutex during mmap operation

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the aedev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.

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

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.

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

remoteproc: core: Fix idafree call while not allocated

In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before idaalloc is called.

In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from warn+0x80/0x12c [ 4.260134] warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc

Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.

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

safesetid: check size of policy writes

syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handlepolicyupdate(), triggering a warning in kmalloc.

Check the size specified for write buffers before allocating.

[PM: subject tweak]

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

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:consoleunlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIGRAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintkemit+0x193/0x280 printk+0x52/0x6e dumptask+0x114/0x130 memcgroupscantasks+0x76/0x100 dumpheader+0x1fe/0x210 oomkillprocess+0xd1/0x100 outofmemory+0x125/0x570 memcgroupoutofmemory+0xb5/0xd0 trycharge+0x720/0x770 memcgrouptrycharge+0x86/0x180 memcgrouptrychargedelay+0x1c/0x40 doanonymouspage+0xb5/0x390 handlemmfault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.

To fix this issue, call 'condresched' in the 'memcgroupscantasks' function per 1000 iterations. For global OOM, call 'touchsoftlockupwatchdog' per 1000 iterations to avoid this issue.

dlm: fix possible lkbresource null dereference

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

sctp: purge outqueue on stale COOKIE-ECHO handling

sctpstreamupdate() is only invoked when the association is moved into COOKIEWAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->outcurr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed.

However, a corner case exists in sctpsfdo526stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIEECHOED to COOKIEWAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk.

During the rollback, sctpstreamupdate() frees the old stream table and installs a new one, but it does not invalidate stream->outcurr. As a result, outcurr may still point to a freed sctpstreamout entry from the previous stream state.

Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->outcurr->ext, which can lead to use-after-free once the old stream state has been released via sctpstreamfree().

This results in crashes such as (reported by Yuqi):

BUG: KASAN: slab-use-after-free in sctpschedfcfsdequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task minipoc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: minipoc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctpschedfcfsdequeue+0x13a/0x140 sctpoutqflush+0x1603/0x33e0 sctpdosm+0x31c9/0x5d30 sctpassocbhrcv+0x392/0x6f0 sctpinqpush+0x1db/0x270 sctprcv+0x138d/0x3c10

Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIEWAIT restart.

Updating only stream->outcurr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.

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

drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1

[Why] If the dummy values in populatedummydmlsurfacecfg() aren't updated then they can lead to a divide by zero in downstream callers like CalculateVMAndRowBytes()

[How] Initialize dummy value to a value to avoid divide by zero.

dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA

drm/amd/display: Do not set DRR on pipe Commit