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

netfilter: handle unreadable frags

sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skbfragsreadable(skb) returns false) is processed by the u32 module, skbcopybits() will safely return a negative error code [..]

xtu32: bail out with hotdrop in this case. gatherfrags: return -1, just as if we had no fragment header. nfnetlinkqueue: restrict to the linear part. nfnetlinklog: restrict to the linear part.

v2: - skbzerocopy helpers don't copy readable flag, i.e. nfnetlinkqueue is broken too xtu32 shouldn't return true if hotdrop was set.

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

HID: hid-goodix-spi: validate report size to prevent stack buffer overflow

goodixhidsetrawreport() builds a protocol frame in a 128-byte stack buffer (tmpbuf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HIDMAXBUFFERSIZE (16384) by default, while the driver does not set hidlldriver.maxbuffersize and performs no bounds checking before copying the payload:

memcpy(tmpbuf + txlen, buf, len);

A hidraw SETREPORT ioctl with a report larger than ~116 bytes overflows the stack buffer.

Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

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

bpf: Validate BTF repeated field counts before expansion

btfparsestructmetas() walks user-supplied BTF during BPFBTFLOAD, and btfrepeatfields() expands repeatable fields from array elements into the fixed BTFFIELDSMAX scratch array used by btfparsefields().

The remaining-capacity check performs the expanded field count calculation in u32. A malformed BTF can wrap that calculation, causing the check to pass even when the expanded field count exceeds the scratch array capacity. The following memcpy() can then write past the end of the array.

Use checked addition and multiplication before copying repeated fields and reject impossible counts.

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

KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits

Move the handling of fastpath userspace exits into vendor code to ensure KVM runs vendor specific operations that need to run before userspace gains control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM needs to flush the PML buffer prior to exiting to userspace, otherwise any memory written by the final KVMRUN might never be flagged as dirty.

Note, waiting to snapshot CR0 and CR3 until svmhandleexit() is flawed in general, as that risks consuming stale state in a fastpath handler. That will be addressed in a future change.

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

schedext: Avoid UAF in scxrootenableworkfn() init failure path

In scxrootenableworkfn(), puttaskstruct(p) is called before scxerror() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF.

Move puttaskstruct() past scxerror().

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

netfs: Fix streaming write being overwritten

In order to avoid reading whilst writing, netfslib will allow "streaming writes" in which dirty data is stored directly into folios without reading them first. Such folios are marked dirty but may not be marked uptodate. If a folio is entirely written by a streaming write, uptodate will be set, otherwise it will have a netfsfolio struct attached to ->private recording the dirty region.

In the event that a partially written streaming write page is to be overwritten entirely by a single write(), netfsperformwrite() will try to copy over it, but doesn't discard the netfsfolio if it succeeds; further, it doesn't correctly handle a partial copy that overwrites some of the dirty data.

Fix this by the following:

(1) If the folio is successfully overwritten, free the netfsfolio struct before marking the page uptodate.

(2) If the copy to the folio partially fails, but short of the dirty data, just ignore the copy.

(3) If the copy partially fails and overwrites some of the dirty data, accept the copy, update the netfsfolio struct to record the new data. If the folio is now filled, free the netfsfolio and set uptodate, otherwise return a partial write.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0 0x927c0 write 0x63fb8 0x53c8 0 copyrange 0xb704 0x19b9 0x24429 0x79380 write 0x2402b 0x144a2 0x90660 write 0x204d5 0x140a0 0x927c0 copyrange 0x1f72c 0x137d0 0x7a906 0x927c0 read 0x00000 0x20000 0x9157c read 0x20000 0x20000 0x9157c read 0x40000 0x20000 0x9157c read 0x60000 0x20000 0x9157c read 0x7e1a0 0xcfb9 0x9157c

on cifs with the default cache option.

It shows folio 0x24 misbehaving if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

netfs: Fix netfsreadfolio() to wait on writeback

Fix netfsreadfolio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag).

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

rust: arm64: set uwtable llvm module flag for CONFIGUNWINDTABLES

Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the uwtable annotation for functions, but not for the module. This means that compiler-generated functions such as 'asan.modulector' do not receive the uwtable annotation.

When CONFIGUNWINDPATCHPACINTOSCS is enabled, this leads to boot failures because the dwarf information emitted for the kasan constructors is wrong, which causes the SCS boot patching code to patch the constructor in an illegal manner. Specifically, the paciasp instruction is patched, but the autiasp instruction is not. This mismatch leads to a crash when the constructor is called during boot.

================================================================== BUG: KASAN: global-out-of-bounds in dobasicsetup+0x4c/0x90 Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1

Specifically the faulting instruction is the (fn)() to invoke the constructor in doctors() of the init/main.c file.

Once the fix lands in rustc, this flag can be made conditional on the rustc version. Note that passing the flag on a rustc with the fix present has no effect.

[ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20).

Thus add a version check as discussed.

- Miguel ]

[ Adjusted link and comment. - Miguel ]

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

netdev: fix double-free in netdevnlbindrxdoit()

Sashiko flags that genlmsgreply() always consumes the skb. The error path calls nlmsgfree(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsgreply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf.

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

net: ibm: emac: Fix use-after-free during device removal

The driver was using devmregisternetdev() which causes unregisternetdev() to be deferred until the devres cleanup phase, which runs after emacremove() returns. This creates a use-after-free window where:

1. emacremove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emacremove() returns 3. devres cleanup runs and finally calls unregisternetdev()

During step 3, the network stack might still process packets, triggering emacirq(), emacpoll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.).

Fix this by replacing devmregisternetdev() with manual registernetdev() and calling unregisternetdev() at the beginning of emacremove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released.

The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emacremove) - platformsetdrvdata() is only called after successful registration, so emacremove() only runs for fully registered devices - unregisternetdev() is idempotent and safe to call on any registered device

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

ALSA: timer: Forcibly close timer instances at closing

When sndtimer object is freed via sndtimerfree() and still pending sndtimerinstance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIGSNDUTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer.

This patch is an attempt to paper over the problem above: now instead of just unlinking, call sndtimercloselocked forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since sndtimerclose() might be called later by the driver that created that instance, the check of SNDRVTIMERIFLGDEAD is added at the beginning, too.

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

iouring/net: inherit IORINGCQEFBUFMORE across bundle recv retries

When a bundle recv retries inside iorecvfinish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQEFMASK);

Bits listed in CQEFMASK are inherited from the new iteration, and all other bits (notably IORINGCQEFBUFFER and the buffer ID) come from the saved cflags. Before this change CQEFMASK covered only IORINGCQEFSOCKNONEMPTY and IORINGCQEFMORE.

When using provided buffer rings (IOUPBUFRINGINC) with incremental mode, and bundle recv, iokbufinccommit() can leave the head ring entry partially consumed, ioputkbufs() then sets IORINGCQEFBUFMORE on the returned cflags so userspace knows the buffer ID will be reused for subsequent completions.

Because IORINGCQEFBUFMORE was not in CQEFMASK, the merge above silently dropped it whenever the final retry iteration partially consumed the buffer, and the subsequent req->cqe.flags = cflags & ~CQEFMASK save would have left a stale IORINGCQEFBUFMORE in the carried-over cflags had one been present. Userspace would then wrongfully advance it ring head past an entry the kernel still uses.

Add IORINGCQEFBUFMORE to CQEFMASK so it is both inherited from the new iteration into the user-visible CQE and stripped from the saved cflags between iterations.

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

ALSA: timer: Fix UAF at sndtimeruserparams()

At releasing a timer object, e.g. when a userspace timer (CONFIGSNDUTIMER) gets closed and sndtimerfree() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses.

Fortunately, most of ioctls dealing with the timer instance list already have the protection with registermutex, and this also avoids such races. But, SNDRVTIMERIOCTLPARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free.

This patch just adds the guard with registermutex to protect sndtimeruserparams() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter.

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

drm/xe: Fix error cleanup in xeexecqueuecreateioctl()

Two error handling issues exist in xeexecqueuecreateioctl():

1. When xehwenginegroupaddexecqueue() fails, the error path jumps to putexecqueue which skips xeexecqueuekill(). If the VM is in preempt fence mode, xevmaddcomputeexecqueue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed.

2. When xaalloc() fails after xehwenginegroupaddexecqueue() has succeeded, the error path does not call xehwenginegroupdelexecqueue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free.

Fix both by: - Changing the xehwenginegroupaddexecqueue() failure path to jump to killexecqueue so that xeexecqueuekill() properly removes the queue from the VM's compute list. - Adding a delhwenginegroup label before killexecqueue for the xaalloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup.

(cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8)

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

greybus: gb-beagleplay: bound bootloader receive buffering

cc1352bootloaderrx() appends each serdev chunk into the fixed rxbuffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length.

Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rxbuffer.

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

of: unittest: fix use-after-free in ofunittestchangeset()

The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct devicenode. The call to ofnodeput(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free.

Fix this by moving the ofnodeput() call after the last access to 'parent', avoiding the UAF.

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

wifi: mac80211: use safe list iteration in radar detect work

The call to ieee80211dfscaccancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.

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

ice: fix double free in icesfethactivate() error path

When auxiliarydeviceadd() fails, icesfethactivate() jumps to auxdevuninit and calls auxiliarydeviceuninit(&sfdev->adev).

The device release callback icesfdevrelease() frees sfdev, but the current error path falls through to sfdevfree and calls kfree(sfdev) again, causing a double free.

Keep kfree(sfdev) for the auxiliarydeviceinit() failure path, but avoid falling through to sfdevfree after auxiliarydeviceuninit().

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

schedext: Remove redundant cssput() in scxcgroupinit()

The iterator cssforeachdescendantpre() walks the cgroup hierarchy under cgrouplock(). It does not increment the reference counts on yielded css structs.

According to the cgroup documentation, cssput() should only be used to release a reference obtained via cssget() or csstrygetonline(). Since the iterator does not use either of these to acquire a reference, calling cssput() in the error path of scxcgroupinit() causes a refcount underflow.

Remove the unbalanced cssput() to prevent a potential Use-After-Free (UAF) vulnerability.

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

nsfs: tighten permission checks for ns iteration ioctls

Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use mayseeallnamespaces() helper that centralizes this policy until the nstree adapts.

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

iio: accel: adxl380: Avoid reading more entries than present in FIFO

The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present.

To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N.

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

mm: filemap: fix nrpages calculation overflow in filemapmappages()

When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state":

" [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount "

After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIGDEBUGVM config, I can reproduce the crash as well and captured the first warning where the issue appears:

" [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4daaops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VMWARNONFOLIO((Generic((page + nrpages - 1), const struct page : (const struct folio )compoundhead(page + nrpages - 1), struct page : (struct folio )compoundhead(page + nrpages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folioaddfilermapptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folioaddfilermapptes+0x3b8/0x468 (P) [ 734.469555] setpterange+0xd8/0x2f8 [ 734.469566] filemapmapfoliorange+0x190/0x400 [ 734.469579] filemapmappages+0x348/0x638 [ 734.469583] dofaultaround+0x140/0x198 ...... [ 734.469640] el0t64sync+0x184/0x188 "

The code that triggers the warning is: "VMWARNONFOLIO(pagefolio(page + nrpages - 1) != folio, folio)", which indicates that setpterange() tried to map beyond the large folio’s size.

By adding more debug information, I found that 'nrpages' had overflowed in filemapmappages(), causing setpterange() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->mapcount).

After above analysis, I think the possible race is as follows:

CPU 0 CPU 1 filemapmappages() ext4setattr() //get and lock folio with old inode->isize nextuptodatefolio()

....... //shrink the inode->isize isizewrite(inode, attr->iasize);

//calculate the endpgoff with the new inode->isize fileend = DIVROUNDUP(isizeread(mapping->host), PAGESIZE) - 1; endpgoff = min(endpgoff, fileend);

...... //nrpages can be overflowed, cause xas.xaindex > endpgoff end = folionextindex(folio) - 1; nrpages = min(end, endpgoff) - xas.xaindex + 1;

...... //map large folio filemapmapfoliorange() ...... //truncate folios truncatepagecache(inode, inode->isize);

To fix this issue, move the 'endpgoff' calculation before nextuptodatefolio(), so the retrieved folio stays consistent with the file end to avoid ---truncated---

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

net: lan966x: fix use-after-free and leak in lan966xfdmareload()

When lan966xfdmareload() fails to allocate new RX buffers, the restore path restarts DMA using old descriptors whose pages were already freed via lan966xfdmarxfreepages(). Since pagepoolputfullpage() can release pages back to the buddy allocator, the hardware may DMA into memory now owned by other kernel subsystems.

Additionally, on the restore path, the newly created page pool (if allocation partially succeeded) is overwritten without being destroyed, leaking it.

Fix both issues by deferring the release of old pages until after the new allocation succeeds. Save the old page array before the allocation so old pages can be freed on the success path. On the failure path, the old descriptors, pages and page pool are all still valid, making the restore safe. Also ensure the restore path re-enables NAPI and wakes the netdev, matching the success path.

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

media: mediatek: vcodec: fix use-after-free in encoder release path

The fopsvcodecrelease() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encodework. This creates a race window where the workqueue handler (mtkvencworker) may still be accessing the context memory after it has been freed.

Race condition:

CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fopsvcodecrelease() v4l2m2mctxrelease() v4l2m2mcanceljob() // waits for m2m job "done" mtkvencworker() v4l2m2mjobfinish() // m2m job "done" // BUT worker still running! // post-jobfinish access: other ctx dereferences // UAF if ctx already freed // returns (job "done") kfree(ctx) // ctx freed

Root cause: The v4l2m2mctxrelease() only waits for the m2m job lifecycle (via TRANSRUNNING flag), not the workqueue lifecycle. After v4l2m2mjobfinish() is called, the m2m framework considers the job complete and v4l2m2mctxrelease() returns, but the worker function continues executing and may still access ctx.

The work is queued during encode operations via: queuework(ctx->dev->encodeworkqueue, &ctx->encodework) The worker function accesses ctx->m2mctx, ctx->dev, and other ctx fields even after calling v4l2m2mjobfinish().

This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-jobfinish race window. KASAN detected:

BUG: KASAN: slab-use-after-free in mtkvencworker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12

Workqueue: mtkvcodecencwq mtkvencworker

Allocated by task 47: kasankmalloc+0x7f/0x90 fopsvcodecopen+0x85/0x1a0

Freed by task 47: kasanslabfree+0x43/0x70 kfree+0xee/0x3a0 fopsvcodecrelease+0xb7/0x190

Fix this by calling cancelworksync(&ctx->encodework) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed.

Placement rationale: The fix is placed after v4l2ctrlhandlerfree() and before listdelinit(&ctx->list). At this point, all m2m operations are done (v4l2m2mctxrelease() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it.

Note: The open error path does NOT need cancelworksync() because INITWORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during devicerun() operations.

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

media: em28xx: fix use-after-free in em28xxv4l2open()

em28xxv4l2open() reads dev->v4l2 without holding dev->lock, creating a race with em28xxv4l2init()'s error path and em28xxv4l2fini(), both of which free the em28xxv4l2 struct and set dev->v4l2 to NULL under dev->lock.

This race leads to two issues: - use-after-free in v4l2fhinit() when accessing vdev->ctrlhandler, since the videodevice is embedded in the freed em28xxv4l2 struct. - NULL pointer dereference in em28xxresolutionset() when accessing v4l2->norm, since dev->v4l2 has been set to NULL.

Fix this by moving the mutexlock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.

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

ALSA: 6fire: fix use-after-free on disconnect

In usb6firechipabort(), the chip struct is allocated as the card's private data (via sndcardnew with sizeof(struct sfirechip)). When sndcardfreewhenclosed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory.

Call trace: usb6firechipabort sound/usb/6fire/chip.c:59 [inline] usb6firechipdisconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usbunbindinterface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hubevent+0x1a04/0x4518 drivers/usb/core/hub.c:5953

Fix by moving the card lifecycle out of usb6firechipabort() and into usb6firechipdisconnect(). The card pointer is saved in a local before any teardown, sndcarddisconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and sndcardfreewhenclosed() is called last so chip is never accessed after the card may be freed.

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

bcache: fix cacheddev.sbbio use-after-free and crash

In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:

[6888366.280350] Call Trace: [6888366.280452] blkupdaterequest+0x14e/0x370 [6888366.280561] blkmqendrequest+0x1a/0x130 [6888366.280671] rbdimghandlerequest+0x1a0/0x1b0 [rbd] [6888366.280792] rbdobjhandlerequest+0x32/0x40 [rbd] [6888366.280903] completerequest+0x22/0x70 [libceph] [6888366.281032] osddispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inetrecvmsg+0x5b/0xd0 [6888366.281272] ? cephtcprecvmsg+0x6f/0xa0 [libceph] [6888366.281405] cephconprocessmessage+0x79/0x140 [libceph] [6888366.281534] cephconv1tryread+0x5d7/0xf30 [libceph] [6888366.281661] cephconworkfn+0x329/0x680 [libceph]

After analyzing the coredump file, we found that the address of dc->sbbio has been freed. We know that cacheddev is only freed when it is stopped.

Since sbbio is a part of struct cacheddev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.

This patch hopes to wait for sbwrite to complete in cacheddevfree.

It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.

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

netfs: Fix read abandonment during retry

Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes).

Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEEDRETRY set).

Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it.

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

drm/xe: Open-code GGTT MMIO access protection

GGTT MMIO access is currently protected by hotplug (drmdeventer), which works correctly when the driver loads successfully and is later unbound or unloaded. However, if driver load fails, this protection is insufficient because drmdevunplug() is never called.

Additionally, devm release functions cannot guarantee that all BOs with GGTT mappings are destroyed before the GGTT MMIO region is removed, as some BOs may be freed asynchronously by worker threads.

To address this, introduce an open-coded flag, protected by the GGTT lock, that guards GGTT MMIO access. The flag is cleared during the devfiniggtt devm release function to ensure MMIO access is disabled once teardown begins.

(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)