| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the
FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into
the connection's async_requests list via setup_async_work(). The cancel
callback smb2_remove_blocked_lock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no
longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the
cleanup path calls locks_free_lock(flock) without dequeuing the work from
the async_requests list. Concurrently, smb2_cancel() walks the list
under conn->request_lock and invokes the cancel callback, which then
dereferences the already freed 'flock'. This leads to a slab-use-after-free
inside __wake_up_common.
Fix this by restructuring the cleanup logic after the worker returns
from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and
release_async_work(work) to the top of the cleanup block. This guarantees
that the async work is completely dequeued and serialized under
conn->request_lock before locks_free_lock(flock) is called, rendering
the flock unreachable for any concurrent smb2_cancel(). |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: resolve SWN tcon from live registrations
cifs_swn_notify() looks up a witness registration by id under
cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's
cached tcon pointer. That pointer is not a lifetime reference, and it is
not a stable representative once cifs_get_swn_reg() lets multiple tcons
for the same net/share name share one registration id.
A same-share second mount can keep the cifs_swn_reg alive after the first
tcon unregisters and is freed. The registration then still points at the
freed first tcon, so taking tc_lock or incrementing tc_count through
swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while
holding cifs_swnreg_idr_mutex also violates the documented CIFS lock
order.
Fix this by making the registration store only the stable witness
identity: id, net name, share name, and notify flags. When a notify
arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex,
then find and pin a live witness tcon that currently matches the net/share
pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification
path uses that pinned tcon directly and drops the reference when done.
Registration and unregister messages now use the live tcon passed by the
caller instead of a cached tcon in the registration. The final unregister
send is folded into cifs_swn_unregister() while the registration is still
protected by cifs_swnreg_idr_mutex. This removes the previous
find/drop/reacquire raw-pointer window. The release path only removes the
idr entry and frees the stable identity strings.
This preserves the intended one-registration/many-tcon behavior: a
registration id represents a net/share pair, and notify handling acts on a
live representative selected at use time. It also preserves CLIENT_MOVE
ordering for the representative tcon because the old-IP unregister is sent
before cifs_swn_register() sends the new-IP register. |
| In the Linux kernel, the following vulnerability has been resolved:
ipc: limit next_id allocation to the valid ID range
The checkpoint/restore sysctl path can request the next SysV IPC id
through ids->next_id. ipc_idr_alloc() currently forwards that request to
idr_alloc() with an open-ended upper bound.
If the valid tail of the SysV IPC id space is full, the allocation can
spill beyond ipc_mni. The returned SysV IPC id still uses the normal
index encoding, so later lookup and removal can target the wrong slot.
This leaves the real IDR entry behind and breaks the IDR state for the
object.
The bug is in ipc_idr_alloc() in the checkpoint/restore path.
1. ids->next_id is passed to:
idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)
2. The zero upper bound makes the allocation effectively open-ended.
Once the valid SysV IPC tail is occupied, idr_alloc() can spill past
ipc_mni and allocate an entry beyond the valid IPC id range.
3. The new object id is still encoded with the narrower SysV IPC index
width:
new->id = (new->seq << ipcmni_seq_shift()) + idx
4. Later removal goes through ipc_rmid(), which uses:
ipcid_to_idx(ipcp->id)
That truncates the real IDR index. An object actually stored at a
high index can then be removed as if it lived at a low in-range
index.
5. For shared memory, shm_destroy() frees the current object anyway, but
the real high IDR slot is left behind as a dangling pointer.
6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry
and dereferences freed memory.
Prevent this by bounding the requested allocation to ipc_mni so the
checkpoint/restore path fails once the valid range is exhausted. |
| Issue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData
digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may
incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent
use of the BIO by the calling application results in a use-after-free
condition.
In the common case this occurs when the application later calls
BIO_free() on the BIO originally passed to PKCS7_verify(). Depending
on allocator behavior and application-specific BIO usage patterns, this
may result in a crash or other memory corruption. In some application
contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL
PKCS#7 APIs may be affected. Applications using the CMS APIs for this
processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary. |
| A malicious IMAP server can trigger use-after-free and heap-memory disclosure by sending a crafted ID response. Heap contents can ultimately be persisted to prefs.js. This vulnerability was fixed in Thunderbird 155, Thunderbird 140.15, and Thunderbird 153.2. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL
Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on
double SMB2_CANCEL") made smb2_cancel() skip a work whose state is
KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But
KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same
freeing producer path is reached for CLOSED too:
SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets
the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock()
worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s
the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes
the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the
cancelled branch, skips release_async_work(). The work stays on
conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock
pointing at the freed file_lock.
A subsequent SMB2_CANCEL for the same AsyncId then passes the
KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so
smb2_cancel() fires cancel_fn again over the freed file_lock -- the same
use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL:
BUG: KASAN: slab-use-after-free in __locks_delete_block
__locks_delete_block
locks_delete_block
ksmbd_vfs_posix_lock_unblock
smb2_remove_blocked_lock
smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn
handle_ksmbd_work
Allocated by ...: locks_alloc_lock <- smb2_lock
Freed by ...: locks_free_lock <- smb2_lock (non-ACTIVE early-exit)
... cache file_lock_cache of size 192
Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with
KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is
silent on that kernel, so the splat is attributable to the CLOSE trigger.
Only an ACTIVE deferred work may have its cancel_fn fired: both terminal
states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees
the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE
so any non-active work is skipped. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()
The VF2PF interrupt handler queues PF-side response work that stores a
raw pointer to per-VF state (struct adf_accel_vf_info). Currently,
adf_disable_sriov() destroys per-VF mutexes and frees vf_info without
stopping new VF2PF work or waiting for in-flight workers to complete. A
concurrently scheduled or already queued worker can then dereference
freed memory.
This manifests as a use-after-free when KASAN is enabled:
BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0
Write of size 8 at addr 0000000000000260 by task kworker/24:2/...
Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat]
Call Trace:
kasan_report+0x119/0x140
mutex_lock+0x76/0xe0
adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat]
adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat]
adf_iov_send_resp+0x8c/0xe0 [intel_qat]
process_one_work+0x6ac/0xfd0
worker_thread+0x4dd/0xd30
kthread+0x326/0x410
ret_from_fork+0x33b/0x670
Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker
processing, and interrupt re-enabling during teardown. Set this flag
atomically with the hardware interrupt mask inside
adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE
cluster MSI-X interrupt and flush the PF response workqueue before
tearing down per-VF locks and state so all in-flight work completes
before vf_info is destroyed.
Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and
unmask all VF2PF interrupts under the same lock when SR-IOV is
re-enabled. This ensures the software flag and hardware state transition
atomically on both the enable and disable paths. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - filter out async aead implementations at alloc
krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and
rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL
completion callback and treat any negative return from
crypto_aead_{encrypt,decrypt}() as terminal, falling through to
kfree_sensitive(buffer). When the encrypt_name resolves to an
async AEAD instance the request returns -EINPROGRESS, the buffer
is freed while the backend's worker still holds a pointer, and the
worker dereferences the freed slab on completion.
KASAN report under UML+SLUB with a synthetic async aead backend
bound to krb5->encrypt_name:
BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7
The helpers were written synchronously, so filter the async
instances out at allocation time instead of plumbing
crypto_wait_req() through every call site.
Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and
net/ceph/crypto.c on systems with an async AEAD provider bound to
the krb5 enctype name. |
| Use after free in Browser in Google Chrome prior to 152.0.7977.75 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix page UAF in map_range()
map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via
perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are
serialized by rb->aux_mutex, and mmap_mutex is per event.
Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race
rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows:
CPU 0 CPU 1
===== =====
rb_alloc_aux() map_range()
[1]: allocate rb->aux_pages[0]
[2]: rb->aux_nr_pages++
[3]: perf_mmap_to_page()
returns rb->aux_pages[0]
[4]: map it as VM_PFNMAP
[5]: rb->aux_pgoff = 1
munmap the page
[6]: free rb->aux_pages[0]
Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a
mapping to a freed physical frame.
Fix this by taking rb->aux_mutex across the page walk in map_range(). |
| In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-lpspi: terminate the RX channel on TX prepare failure path
When dmaengine_prep_slave_sg() fails for the TX channel, the error path
terminates the TX DMA channel but leaves the RX channel running. Since
the RX channel was already submitted and issued prior to preparing
the TX descriptor, returning -EINVAL causes the SPI core to unmap the
DMA buffers while the RX DMA engine continues writing to them, leading
to potential memory corruption or use-after-free.
Terminate the RX channel before returning on the TX prepare failure path. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: iowarrior: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked") |
| In the Linux kernel, the following vulnerability has been resolved:
USB: iowarrior: fix use-after-free on disconnect
Submitted write URBs are not stopped on close() and therefore need to be
stopped unconditionally on disconnect() to avoid use-after-free in the
completion handler. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: ldusb: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is
non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked") |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: loongson - Remove broken and unused loongson-rng
The loongson-rng rng_alg has several vulnerabilities, including not
providing forward security, and a use-after-free bug due to the use of
wait_for_completion_interruptible().
Meanwhile, the rng_alg framework doesn't really have any purpose in the
first place other than to access the software algorithms crypto/drbg.c
and crypto/jitterentropy.c. Hardware-specific rng_algs have no
in-kernel user, and unlike hwrng there's no feed into the actual Linux
RNG. As such, there's really no point to this code. There are of
course other rng_alg drivers that are similarly unused, but they're
similarly in the process of being phased out, e.g.
https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org
Given that, there's no point in fixing forward these vulnerabilities,
and it makes much more sense to simply roll back the addition of this
driver. If this platform provides TRNG (not PRNG) functionality, it
could make sense to add a hwrng driver, but it would be quite different. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone
If a streaming write is made, this will leave the relevant modified folio
in a not-uptodate, but dirty state with a netfs_folio struct hung off of
folio->private indicating the dirty range. Subsequently truncating the
file such that the dirty data in the folio is removed, but the first part
of the folio theoretically remains will cause the netfs_folio struct to be
discarded... but will leave the dirty flag set.
If the folio is then read via mmap(), netfs_read_folio() will see that the
page is dirty and jump to netfs_read_gaps() to fill in the missing bits.
netfs_read_gaps(), however, expects there to be a netfs_folio struct
present and can oops because truncate removed it.
Fix this by calling folio_cancel_dirty() in netfs_invalidate_folio() in the
event that all the dirty data in the folio is erased (as nfs does).
Also add some tracepoints to log modifications to a dirty page.
This can be reproduced with something like:
dd if=/dev/zero of=/xfstest.test/foo bs=1M count=1
umount /xfstest.test
mount /xfstest.test
xfs_io -c "w 0xbbbf 0xf96c" \
-c "truncate 0xbbbf" \
-c "mmap -r 0xb000 0x11000" \
-c "mr 0xb000 0x11000" \
/xfstest.test/foo
with fscaching disabled (otherwise streaming writes are suppressed) and a
change to netfs_perform_write() to disallow streaming writes if the fd is
open O_RDWR:
if (//(file->f_mode & FMODE_READ) || <--- comment this out
netfs_is_cache_enabled(ctx)) {
It should be reproducible even without this change, but if prevents the
above trivial xfs_io command from reproducing it.
Note that the initial dd is important: the file must start out sufficiently
large that the zero-point logic doesn't just clear the gaps because it
knows there's nothing in the file to read yet. Unmounting and mounting is
needed to clear the pagecache (there are other ways to do that that may
also work).
This was initially reproduced with the generic/522 xfstest on some patches
that remove the FMODE_READ restriction. |
| In the Linux kernel, the following vulnerability has been resolved:
6lowpan: fix NHC entry use-after-free on error path
lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding
lowpan_nhc_lock. If the descriptor has no uncompress callback, the error
path drops the lock before printing nhc->name.
lowpan_nhc_del() removes descriptors under the same lock and then relies
on synchronize_net() before the owning module can be unloaded. That only
waits for net RX RCU readers. lowpan_header_decompress() is also exported
and can be reached from callers that are not necessarily covered by the net
core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive
path.
This leaves a race where one task drops lowpan_nhc_lock in the error path,
another task unregisters and frees the matching descriptor after
synchronize_net() returns, and the first task then dereferences nhc->name
for the warning.
With the post-unlock window widened, KASAN reports:
BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220
Read of size 8
lowpan_nhc_do_uncompression
lowpan_header_decompress
Fix this by printing the warning before dropping lowpan_nhc_lock, so the
descriptor name is read while unregister is still excluded. The malformed
packet is still rejected with -ENOTSUPP. |
| In the Linux kernel, the following vulnerability has been resolved:
fprobe: Fix unregister_fprobe() to wait for RCU grace period
Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer")
changed fprobe to register struct fprobe to an rcu-hlist, but it forgot
to wait for RCU GP. Thus there can be use-after-free if the fprobe is
released right after unregistering. This can be happened on fprobe
event and sample module code.
To fix this issue, add synchronize_rcu() in unregister_fprobe().
Note that BPF is OK because fprobe is used as a part of
bpf_kprobe_multi_link. This unregisters its fprobe in
bpf_kprobe_multi_link_release() and it is deallocated via
bpf_kprobe_multi_link_dealloc(), which is invoked from
bpf_link_defer_dealloc_rcu_gp() RCU callback.
For BPF, this also introduced unregister_fprobe_async() which does
NOT wait for RCU grace priod. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: misc: usbio: fix disconnect UAF in client teardown
usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each
auxiliary device. auxiliary_device_uninit() drops the device reference, and
for an unbound child that can run usbio_auxdev_release() and free the
containing struct usbio_client.
list_for_each_entry_reverse() advances after the loop body by reading
client->link.prev. If the current client is freed by
auxiliary_device_uninit(), the iterator dereferences freed memory.
Use list_for_each_entry_safe_reverse() so the previous client is
cached before the body can drop the final reference. This preserves
reverse teardown order while keeping the next iterator cursor independent
of the current client's lifetime.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150
Call Trace:
<TASK>
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x630
? usbio_disconnect+0x12e/0x150
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x188/0x320
? usbio_disconnect+0x12e/0x150
kasan_report+0xe0/0x110
? usbio_disconnect+0x12e/0x150
usbio_disconnect+0x12e/0x150
usb_unbind_interface+0xf3/0x400
really_probe+0x316/0x660
__driver_probe_device+0x106/0x240
driver_probe_device+0x4a/0x110
__device_attach_driver+0xf1/0x1a0
? __pfx___device_attach_driver+0x10/0x10
bus_for_each_drv+0xf9/0x160
? __pfx_bus_for_each_drv+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? trace_hardirqs_on+0x18/0x130
? srso_alias_return_thunk+0x5/0xfbef5
? _raw_spin_unlock_irqrestore+0x44/0x60
__device_attach+0x133/0x2a0
? __pfx___device_attach+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? do_raw_spin_unlock+0x9a/0x100
? srso_alias_return_thunk+0x5/0xfbef5
device_initial_probe+0x55/0x70
bus_probe_device+0x4a/0xd0
device_add+0x9b9/0xc10
? __pfx_device_add+0x10/0x10
? _raw_spin_unlock_irqrestore+0x44/0x60
? srso_alias_return_thunk+0x5/0xfbef5
? lockdep_hardirqs_on_prepare+0xea/0x1a0
? srso_alias_return_thunk+0x5/0xfbef5
? usb_enable_lpm+0x3c/0x260
usb_set_configuration+0xb64/0xf20
usb_generic_driver_probe+0x5f/0x90
usb_probe_device+0x71/0x1b0
really_probe+0x46b/0x660
__driver_probe_device+0x106/0x240
driver_probe_device+0x4a/0x110
__device_attach_driver+0xf1/0x1a0
? __pfx___device_attach_driver+0x10/0x10
bus_for_each_drv+0xf9/0x160
? __pfx_bus_for_each_drv+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? trace_hardirqs_on+0x18/0x130
? srso_alias_return_thunk+0x5/0xfbef5
? _raw_spin_unlock_irqrestore+0x44/0x60
__device_attach+0x133/0x2a0
? __pfx___device_attach+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? do_raw_spin_unlock+0x9a/0x100
? srso_alias_return_thunk+0x5/0xfbef5
device_initial_probe+0x55/0x70
bus_probe_device+0x4a/0xd0
device_add+0x9b9/0xc10
? __pfx_device_add+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? add_device_randomness+0xb7/0xf0
usb_new_device+0x492/0x870
hub_event+0x1b10/0x29c0
? __pfx_hub_event+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? lock_acquire+0x187/0x300
? process_one_work+0x475/0xb90
? srso_alias_return_thunk+0x5/0xfbef5
? lock_release+0xc8/0x290
? srso_alias_return_thunk+0x5/0xfbef5
process_one_work+0x4d7/0xb90
? __pfx_process_one_work+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? __list_add_valid_or_report+0x37/0xf0
? __pfx_hub_event+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
worker_thread+0x2d8/0x570
? __pfx_worker_thread+0x10/0x10
kthread+0x1ad/0x1f0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x3c9/0x540
? __pfx_ret_from_fork+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __switch_to+0x2e9/0x730
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_ffa: Snapshot notifier callbacks under lock
Both notification handlers currently look up a notifier callback under
notify_lock, drop the lock, and then dereference the returned
notifier entry. A concurrent unregister can delete and free that
entry in the gap, leaving the handler to dereference stale memory.
Copy the callback pointer and callback data while notify_lock is
still held and invoke the callback only after the lock is dropped.
This keeps the existing callback execution model while removing the
use-after-free window in both the framework and non-framework
notification paths. |
