dm cache: fix issue with background work locking
Drivers: hv: Avoid infinite retry loop in initvpindex()
In the Linux kernel, the following vulnerability has been resolved:
pidnamespace: make zappidnsprocesses() freezable
When the init of a pid namespace exits, zappidnsprocesses() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails:
Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wqbusy=0):
Neither wait is freezable. The first loop sleeps in dowait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIFSIGPENDING and waits again without ever freezing. The final loop sleeps in TASKINTERRUPTIBLE, and since nothing clears TIFSIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends.
Sleep in TASKINTERRUPTIBLE | TASKFREEZABLE in dowait(), so that the freezer can freeze tasks waiting there directly, and in TASKIDLE | TASKFREEZABLE in the final loop, like coredumptaskexit() does.
This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not initialize tracefs work if tracing is disabled
If trace buffer allocation fails during early boot (e.g. in earlytraceinit() -> allocatetracebuffers()), tracingdisabled is left set to 1 and the global trace array events list remains uninitialized.
Later during boot, tracerinittracefs() (invoked via fsinitcall) queues tracerfsinitwork asynchronously without checking if tracing was disabled. When tracerinittracefsworkfunc() runs, it calls eventtraceinit() and inittracertracefs(&globaltrace, NULL) unconditionally. This leads to findeventfile() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops:
BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] findeventfile+0x70/0x3c0 LR [c000000000448874] inittracertracefs+0x274/0xc80 Call Trace: inittracertracefs+0x274/0xc80 tracerinittracefsworkfunc+0x50/0x320 processonework+0x1e8/0x5c0 workerthread+0x1dc/0x3d0 kthread+0x194/0x1b0 startkernelthread+0x14/0x18
Check tracingdisabled at the beginning of tracerinittracefsworkfunc() and return immediately if tracing is disabled or failed to initialize, preventing the crash.
In the Linux kernel, the following vulnerability has been resolved:
iouring: wake ring pollers for local taskwork
With IORINGSETUPDEFERTASKRUN completions are queued as local work, and only become CQEs when the submitter enters the kernel to wait for events. For an application that finds out via poll() or epoll on the ring fd when it is time to do that, iouringpoll() reports EPOLLIN if local work is pending.
That only helps if the work is there at the time of the call. When DEFERTASKRUN was added, ioreqlocalworkadd() did iocqringwake(), which took care of tasks sleeping in poll() as well. Then polling got a wait queue of its own, ->pollwq, and the wake up in ioreqlocalworkadd() was replaced by waking the submitter directly. Since then ->pollwq is only woken when CQEs are committed, which for such a ring is done by the very task that is waiting to be told to:
submitter completion poll(ringfd) iouringpoll() // nothing yet schedule() ioreqlocalworkadd() // ->cqwaitnr: nobody waits // sleeps on
Wake ->pollwq when the first entry is put on the work list. Like for the eventfd, that must not be done right away if the work is queued from a wake up handler, as the chain of wake ups could get back to the wait queue whose lock is held. Use an RCU callback in that case, with a reference to the ring.
In the Linux kernel, the following vulnerability has been resolved:
iouring/poll: avoid retry wakeup loss when dropping ownership
If a wakeup sets IOPOLLRETRYFLAG between the owning task consuming the existing instance of IOPOLLRETRYFLAG and the loop check of iopollcheckevents(), then we stall on processing the request until an unrelated wakeup comes along.
Using atomiccmpxchg instead of atomicsubreturn to guarantee both the count v and pollrefs are 0 and no wake-ups are missed.
In the Linux kernel, the following vulnerability has been resolved:
iouring/timeout: don't lose a cancel as io-wq arms a timeout
An IORINGOPTIMEOUT run by io-wq, because of IOSQEASYNC, has the same problem as poll, futex and waitid. iowqsubmitwork() looks at IOWQWORKCANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeoutlist in vain, while the worker then adds the request and starts the timer:
io-wq worker iotrycancel() iowqsubmitwork() IOWQWORKCANCEL isn't set ioasynccancelone() sets IOWQWORKCANCEL = -EALREADY iotimeoutcancel() = -ENOENT iotimeout() adds the request to ->timeoutlist hrtimerstart() = IOUISSUESKIPCOMPLETE
Nobody looks at the flag again, and the timeout runs its course. At ring exit, iouringtrycancelrequests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout.
Look at the flag under ->timeoutlock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list.
In the Linux kernel, the following vulnerability has been resolved:
KEYS: Fix keyrejectandlink() race with keyring restriction
The restrictlink check in keyrejectandlink() is done before taking the keyring semaphore, racing with a concurrent keyringrestrict() that installs the restriction while holding the semaphore in write mode.
Move the check to after keylinklock(), so it is done under the semaphore, matching the pattern used in keycreateorupdate().
In the Linux kernel, the following vulnerability has been resolved:
io-wq: order the exit bit against worker creation task work
iowqexitworkers() cancels task work for queued worker creation with taskworkcancelmatch(). That has a plain load of task->taskworks.
ioqueueworkercreate() adds the new entry and tests IOWQBITEXIT to cancel it if the workqueue is already on its way out.
That must be ordered. taskworkadd() has a full barrier via cmpxchg(). But iowqexitstart() sets the bit with setbit() which doesn't have any memory ordering.
So afaict, on weakly ordered architectures the exiting task may load taskworks before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with workerrefs and the exiting task waits on workerdone indefinitely.
If the task still has rings then iouringdeltctxnode() provides the barrier via testandsetbit() in iowqsetexitonidle(). When it has closed all rings though that barrier is gone.
Add the barrier after the setbit().
In the Linux kernel, the following vulnerability has been resolved:
iouring: don't flood a cancelling task with taskwork
ioringexitwork() asks each task which has used the ring to remove its tctx node, by taskwork, and repeats that until the list is empty. iotctxexitcb() doesn't touch the node while the task is in iouringcancelgeneric(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing.
That is more than a waste of time. taskworkrun() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exitgroup(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy.
An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARNONONCE(timeafter(jiffies, timeout)) of ioringexitwork(). No privilege is needed for any of this.
If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round.
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix resident conversion in ntfsnewattrflags
When setting sparse/compressed flags on a resident attribute, the function skipped the resident-to-non-resident conversion and terminated.
In the Linux kernel, the following vulnerability has been resolved:
iouring/io-wq: don't hide a link from cancellations
A task that exits cancels its tracked requests and waits until they are gone. iouringcancelgeneric() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed.
When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found:
ioworkerhandlework() ioassigncurrentwork(worker, NULL) iowqfreework(work) ioreqfindnext() // takes the link off the request iofreereq() // task work for the task ioassigncurrentwork(worker, linked) ioruntaskwork() condresched() worker->curwork = linked
It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of iofreereq() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IOWQBITEXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either.
NOP, IOSQEASYNC | IOSQEIOLINK FUTEXWAIT, FUTEX2PRIVATE exit of the thread, or of the process, up to 63us later
With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM):
iouringcancelgeneric doexit
Commit f8b632e89a10 ("iouring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before iofreereq().
Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split iowqfreework() in two.
In the Linux kernel, the following vulnerability has been resolved:
tipc: protect node reset trace dump with node lock
The tipcnoderesetlinks trace event asks tipcnodedump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock.
This permits bearer teardown to free a link while the trace callback is dumping it:
CPU 0 CPU 1 tracetipcnoderesetlinks() tipcnodedump() l = n->links[0].link tipcnodewritelock() kfree(l) n->links[0].link = NULL tipcnodewriteunlock() tipclinkdump(l)
tipclinkdump() then dereferences the stale pointer. KASAN reported:
BUG: KASAN: slab-use-after-free in tipclinkdump Read of size 4 by task poc/115 Call Trace: tipclinkdump+0x10cb/0x16b0 tipcnodedump+0x4bb/0x740 traceeventraweventtipcnodeclass+0x258/0x360 tipcnoderesetlinks+0x14d/0x1a0 tipcrcv+0x13f5/0x3030 tipcudprecv+0x4e3/0x670 Allocated by task 0: tipclinkcreate+0x1e1/0x1020 tipcnodecheckdest+0x7d2/0x11a0 tipcdiscrcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipcnodelinkdown+0x267/0x4b0 tipcnodedeletelinks+0xec/0x160 bearerdisable+0x107/0x260
Take the node write lock around the trace event. This serializes the dump against tipcnodelinkdown(delete=true), which frees the link under the same write lock.
drm/amdgpu: correct reservation fence slots for userq per-vm BOs eviction
A flaw was found in libslirp in icmpforwarderror() in src/ipicmp.c. When constructing an ICMP error packet, the length of the quoted original packet (siplen) was derived from the IP header field iplen without clamping it to the actual mbuf length (msrc->mlen). A truncated or malformed IPv4 packet could cause memcpy to read past the end of the source mbuf on the host heap, embedding residual host memory into the ICMP error packet returned over the virtual network interface. An unprivileged guest or container process able to send crafted packets through libslirp could disclose host heap contents.
A flaw was found in libslirp in ifoutput() in src/if.c. When demoting an interactive session from the fast queue to the batch queue after throughput limits were exceeded, the code called slirpremque() and slirpinsque() on ifm->mnextpkt (an arbitrary packet in the circular session list) instead of the session queue head. This corrupted doubly-linked queue pointers. Subsequent traversals in ifstart() could crash the host process that embeds libslirp (for example QEMU or slirp4netns), resulting in a guest-to-host denial of service.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Reject incomplete event filter expressions
A non-empty expression normally finishes in predicateparse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state.
For example, "commonpid == 1 || commonpid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERFEVENTIOCSETFILTER.
Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Save the event file instead of the compatible histogram
createfieldvarhist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later:
histdata = findcompatiblehist(targethistdata, file); ... / Save the compatible histogram information / varhist->histdata = histdata;
histdata is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregisterfieldvarhists(), which runs when the target is removed:
file = histdata->fieldvarhists[i]->histdata->eventfile;
findcompatiblehist() matches on keys alone, so it can pick one with no variables of its own. checkvarrefs() then returns false and the user can remove it while the target still points at it:
BUG: KASAN: slab-use-after-free in eventhisttriggerfree+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1
Freed by task 1: kfree+0x154/0x420 eventhisttriggerfree+0x1d5/0x320 eventhisttriggerparse+0x35f3/0x69e0 triggerprocessregex+0x1a6/0x250
Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Unregister field variable histograms when the command fails
An action that names a field on another event needs that field as a variable, so createfieldvarhist() registers a second hist trigger on that event to provide it, and records it in targethistdata->fieldvarhists[].
If a later part of the same command fails, createactions() returns an error and eventhisttriggerparse() jumps to outfree. The write fails with -EINVAL and schedswitch gets no trigger, but:
# echo 'hist:keys=pid:ts0=commontimestamp.usecs' >> \ events/sched/schedwaking/trigger # echo 'mysynth u64 lat; int a; int b' >> syntheticevents # echo 'hist:keys=nextpid:wakeuplat=commontimestamp.usecs-$ts0:\ onmatch(sched.schedwaking).mysynth($wakeuplat,prio,nosuchfld)'\ >> events/sched/schedswitch/trigger # cat events/sched/schedwaking/trigger hist:keys=pid:vals=hitcount:ts0=commontimestamp.usecs:sort=hitcount:size=2048:clock=global [active] hist:keys=pid:vals=hitcount:syntheticprio=prio:sort=hitcount:size=2048 [active]
The second histogram is the one created for 'prio'. It is still active and still counting.
outfree reaches destroyfieldvarhists(), which frees the fieldvarhists[] entries, but never unregisterfieldvarhists(), which is what removes the triggers and runs only from eventhisttriggerfree(). The entry is freed and the trigger is left with nothing tracking it.
Unregister the field variable histograms in outfree as well, and record each one as soon as its trigger is registered rather than after the lookup that follows it, so no exit can leave a registered trigger untracked. The entry then belongs to fieldvarhists[] and is released by destroyfieldvarhists(), so freeing it on that exit would be a double free.
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Verify eventcall identity when updating synthevent refcount
In eventhisttriggerparse() and histunregall(), the histogram registration and unregistration paths look up findsynthevent() using traceeventname(file->eventcall) and adjust se->ref if a match is found.
Because findsynthevent() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it.
Introduce findsyntheventcall() to verify that &se->call matches file->eventcall before adjusting se->ref.
In the Linux kernel, the following vulnerability has been resolved:
iouring/wait: don't spin on a stuck overflow list
As long as IOCHECKCQOVERFLOWBIT is set, iocqringwaitschedule() returns right away, before it gets to look at signals or arms the timeout, for iocqringwait() to flush the overflow list. If that doesn't empty the list, and the CQ ring doesn't hold the number of events the caller wants, the loop starts over, with the same result. The task spins in the kernel, and can't be killed.
The assumption is that this can't happen: if CQEs can't be flushed, the ring is full, and minevents is capped to the size of the ring. But:
- With IORINGSETUPCQEMIXED a 32b CQE needs two contiguous entries. It is stuck on the list if a single one is free, and then the ring holds less than cqentries events. A single threaded application that asks for as many events as the ring has entries never gets out of iouringenter().
- Whether the ring is full is up to the CQ head, which the application can write to. While one thread waits for events on an empty ring, another one can move the head back so that the ring looks full and have a CQE overflow. The waiter can't be stopped any more, not even by SIGKILL.
Only the application can make room in the CQ ring. Return to it if the list could not be flushed.
In the Linux kernel, the following vulnerability has been resolved:
keys: Avoid the owner account dereference in named keyring lookup
Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check. findkeyringbyname() reads keyring->user->uid under keyringnamelock, but that lock protects the keyring's name entry and allocation, not its separate keyuser.
A named session-keyring join can overlap a privileged KEYCTLCHOWN on another CPU. If the keyring holds the last reference to its old dynamic keyuser and the ownership transfer succeeds, the following ordering is possible:
Named join Chown findkeyringbyname() keyctlchownkey() readlock(keyringnamelock) downwrite(key->sem) load old keyring->user replace key->user and key->uid upwrite(key->sem) keyput(key) keyuserput(old user): free read old user->uid readunlock(keyringnamelock)
Chown neither takes keyringnamelock nor keysessionmutex, so it can free the old account between the pointer load and the UID read. The lookup then reads freed memory even though the keyring itself is alive.
Use keyring->uid for the mapping check. keyalloc() initializes this inline owner UID and keyctlchownkey() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check.
KASAN report as below:
BUG: KASAN: slab-use-after-free in findkeyringbyname+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
In the Linux kernel, the following vulnerability has been resolved:
keys: Check the authorization payload in process keyring searches
An authorization payload and its saved credentials must remain valid while searchprocesskeyringsrcu() searches the requestor's keyrings. The function validates the authorization key, then separately loads payload.data[0] and unconditionally reads rka->cred. Validation does not prevent requestkeyauthrevoke() from clearing the payload.
A request-key helper can assume authority and fork a descendant that inherits the authorization key. If the descendant misses in its own keyrings, it falls back to the saved requestor credentials. Successful target instantiation invalidates the authorization key without clearing the payload. After the helper exits, UMHWAITPROC returns to the requester, which calls completerequestkey() and revokes that key.
With the descendant paused after validation, the paths can interleave as follows:
1. The descendant enters searchprocesskeyringsrcu() under RCU and keyvalidate() succeeds. 2. The helper instantiates the target, invalidates the authorization key, and exits. 3. The requester resumes from UMHWAITPROC, calls completerequestkey(), and revokes the authorization key. requestkeyauthrevoke() sets its payload pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred.
This NULL dereference can oops the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared.
Load the payload with dereferencekeyrcu() and require a non-NULL result before validating the authorization key and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's RCU read-side section; a cleared payload skips the fallback search and follows the existing error selection.
KASAN report as below:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:searchprocesskeyringsrcu+0x32b/0x790
In the Linux kernel, the following vulnerability has been resolved:
keys: Protect the type name while describing a key
keyctldescribekey() must keep the key type's name alive until kasprintf() has consumed it. The retained key reference keeps the key and its description alive, but does not pin the module providing its type. The name is passed to kasprintf() without holding key->sem.
kvasprintf() uses the saved name pointer in two formatting passes, with a GFPKERNEL allocation between them. With AFRXRPC=m, a task that passes View permission before type retirement can overlap a privileged module unload in this order:
1. KEYCTLDESCRIBE looks up the key, saves key->type->name in the kasprintf() arguments and completes the first formatting pass. 2. While the formatter is delayed before its second pass, afrxrpcexit() calls unregisterkeytype(), which removes the type from the registry and waits for keygckeytype(). 3. The collector takes key->sem for writing, retypes the retained key to keytypedead and completes retirement. Unregistration and module exit return, allowing freemodule() to release the type and name. 4. The formatter resumes its second pass and reads the saved name from released module storage, which can fault in string().
Hold key->sem for reading across kasprintf(). The collector then cannot retype the key or complete retirement until both formatting passes have finished. If retirement wins the lock first, formatting uses the core keytypedead name instead. Release the semaphore immediately after kasprintf(), including on allocation failure, before copying to userspace.
Oops report as below:
BUG: unable to handle page fault for address: fffffbfff8054794 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page RIP: 0010:string+0x23f/0x470 Call Trace: vsnprintf+0x330/0x1110
In the Linux kernel, the following vulnerability has been resolved:
keys: make keyring indexes independent of kernel addresses
KEYCTLREAD returns the serial numbers in a keyring in associative-array traversal order. The first word of the index is a public, deterministic hash of the type pointer, domain pointer and description. An unprivileged user can therefore insert keys with known descriptions, predict their order for each possible KASLR slide, and recover the kernel image address. On an x86-64 build with 16 MiB alignment, 45 user keys suffice to distinguish the candidate slides.
Remove the addresses from the whole index, not just its first hash word. Assign each key type and domain a nonzero 64-bit ID and hash those IDs and the description with a once-initialized SipHash key. Use the full IDs in the later index chunks as well. Truncating or hashing the IDs there would lose the guarantee that distinct type/domain/description tuples have a differing index bit.
Allocate IDs lazily since private key types need not be registered. Cache them in the index key so tree walks and copies of an existing index do not need to dereference a type descriptor that may have been unregistered. Keep the 32-bit chunk layout and diffobjects() bit offsets consistent, and retain the separate root slot for keyrings used by recursive search. The key comparison, permissions and userspace data format are unchanged; only the address-dependent in-memory ordering is replaced.
In the Linux kernel, the following vulnerability has been resolved:
keys/trustedkeys: return immediately after TPM unseal failure
trustedtpmunseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed.
Return immediately when unseal fails to preserve the original error.
In the Linux kernel, the following vulnerability has been resolved:
keys: Protect the read method check against type removal
keyctlreadkey() checks key->type->read without holding key->sem. A reference keeps the key alive, but does not pin the module containing its type. A surviving RxRPC key can therefore be read while AFRXRPC is being unloaded:
KEYCTLREAD task Module unload and key GC ---------------- ------------------------ lookupuserkey() permission / possession checks load key->type afrxrpcexit() unregisterkeytype() GC: downwrite(key->sem) GC: retype to keytypedead GC: upwrite(key->sem) unregisterkeytype() returns freemodule() read saved type's read member
The final access can read freed module storage. The read invocation in keyctlreadkey() is already protected by key->sem, but the earlier method check is outside that critical section.
Move the method check into keyctlreadkey(), after keyvalidate() and under its existing read hold on key->sem. The check and invocation then use the same protected type for length queries and every read retry. The GC cannot retype the key until the semaphore is released, and type unregistration waits for that GC pass before the module can be freed.
Return -EOPNOTSUPP when validation succeeds and the type has no read method. A temporary buffer may now be allocated before this result; allocation and copying to userspace remain outside the semaphore.
ftrace: Initialize modname and offset in printrec()
coredump: hold RCU while releasing parked threads
AFFLIB through 3.7.22 contains a heap out-of-bounds write vulnerability in afgetpage() that allows attackers to corrupt heap memory by supplying crafted AFF images with mismatched page and sector sizes. Attackers can set a page size larger than and not a multiple of the sector size, causing the sector zero-fill loop to write past the buffer and crash forensic tools.