| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: midi: Serialize output teardown with event_input
event_process_midi() borrows msynth->output_rfile.output and then
passes the substream to dump_midi() and snd_rawmidi_kernel_write()
without synchronizing with the output open/close transition.
midisynth_use() also publishes output_rfile before
snd_rawmidi_output_params() has finished.
The last midisynth_unuse() can therefore release the same rawmidi file
and free substream->runtime before snd_rawmidi_kernel_write1() takes
its runtime buffer reference. That leaves the event_input path using a
stale substream or runtime and can end in a NULL-deref or use-after-free.
Fix this with two pieces of synchronization. Keep a short IRQ-safe
spinlock only for publishing or clearing output_rfile and for pairing
the output snapshot with an snd_use_lock_t reference. Once
event_process_midi() has taken that in-flight reference, it drops the
spinlock before calling snd_seq_dump_var_event(), dump_midi(), or
snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible
rawmidi file under the same spinlock, waits for the in-flight writers
to drain, and only then drains and releases the saved file.
midisynth_use() likewise opens into a local snd_rawmidi_file and
publishes it only after snd_rawmidi_output_params() succeeds.
The buggy scenario involves two paths, with each column showing the
order within that path:
event_input path: last unuse path:
1. event_process_midi() snapshots 1. midisynth_unuse() starts
output_rfile.output. tearing down output_rfile.
2. dump_midi() reaches 2. snd_rawmidi_kernel_release()
snd_rawmidi_kernel_write() closes the output file.
before runtime is pinned. 3. close_substream() frees
3. The callback keeps using substream->runtime.
the borrowed substream.
Validation reproduced this kernel report:
KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360
RIP: 0033:0x7fde7dd0837f
RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360 |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: fix page fragment cache leak in error path
In nvmet_tcp_alloc_queue(), when a connection is closed during the
allocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN),
the error handling jumps to out_destroy_sq and then to out_ida_remove
without draining the page fragment cache.
Although nvmet_tcp_free_cmd() is called in some error paths to release
individual page fragments, the underlying page cache reference held by
queue->pf_cache is never released. The first allocation using pf_cache
is the call to nvmet_tcp_alloc_cmd() for queue->connect, which happens
after ida_alloc() returns successfully. This results in a page leak each
time a connection fails during allocation, which could lead to memory
exhaustion over time if connections are repeatedly opened and closed.
Fix this by calling page_frag_cache_drain() before freeing the queue
structure in the out_ida_remove label. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe
get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue
buffer, which is mapped into userspace. It validates num_sge against
max_sge, but then re-reads the same field to calculate the memcpy
size. A concurrent userspace thread can modify num_sge between
validation and use, causing a heap buffer overflow when copying the
WQE into qp->resp.srq_wqe.
Read num_sge into a local variable and use it for both the bounds
check and the size calculation. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path
For non-SRQ QPs, the responder reads WQE fields directly from the
shared queue buffer mapped into userspace. This allows a malicious
user to modify fields like num_sge or sge entries while the kernel
is processing the WQE, leading to out-of-bounds reads in
rxe_resp_check_length() and copy_data().
Introduce get_recv_wqe() that validates num_sge and copies the WQE
to a kernel-local buffer before processing, matching the approach
already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is
reused since SRQ and non-SRQ paths are mutually exclusive per QP. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix deadlock in read error recovery path
raid1d and raid10d may resubmit a split md cloned bio while handling
a read error. In this case, resubmitting the bio can lead to a deadlock
if the array is suspended before md_handle_request() acquires an
active_io reference via percpu_ref_tryget_live().
Since the cloned bio already holds an active_io reference,
trying to acquire another reference via percpu_ref_tryget_live()
can lead to a deadlock while the array is suspended.
Fix this by using percpu_ref_get() for md cloned bios. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix error-path detection with md_cloned_bio()
Detect the error path using md_cloned_bio() instead of relying
on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be
NULL or -1 after splitting and resubmitting a failed bio.
As a result, the error path may not be recognized and memory
allocations can incorrectly use GFP_NOIO instead of
(GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under
memory pressure. |
| In the Linux kernel, the following vulnerability has been resolved:
raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path
In raid1_write_request(), each per-mirror loop iteration begins by
incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a
badblock within the requested range, the code jumps to err_handle
without dropping the reference taken for the current mirror.
err_handle's cleanup loop will only decrements for k < i and
r1_bio->bios[k] is non-NULL. The current slot is therefore skipped,
leaving its nr_pending reference leaked permanently. The reference
prevents the rdev from ever being removed, since raid1_remove_conf()
refuses to remove an rdev with nr_pending > 0.
Fix this by calling rdev_dec_pending() before jumping to err_handle. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix inconsistent arvif state in vdev_create error paths
ath12k_mac_vdev_create() has three error path issues that leave arvif
in an inconsistent state:
1. When ath12k_wmi_vdev_create() fails, the function returns directly
without clearing arvif->ar, which was already set before the WMI
call. Subsequent code checking arvif->ar to determine vdev readiness
will see a non-NULL value despite no vdev existing in firmware.
2. When ath12k_wmi_send_peer_delete_cmd() fails in err_peer_del, the
code jumped to err: skipping the DP peer cleanup and vdev rollback,
leaving num_created_vdevs, vdev maps and arvif list membership live.
3. When ath12k_wait_for_peer_delete_done() fails, the code jumped to
err_vdev_del: skipping the DP peer cleanup.
Fix by changing the ath12k_wmi_vdev_create() failure to goto err instead
of returning directly, routing both err_peer_del failure paths through
err_dp_peer_del: for proper DP peer and vdev rollback, and consolidating
the arvif state cleanup at err:.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix NULL deref in change_sta_links for unready link
_ieee80211_set_active_links() calls _ieee80211_link_use_channel() for
each newly-added link and WARN_ON_ONCE()s if it fails. The call uses
assign_on_failure=true, which allows mac80211 to continue despite
driver failures, but when a mac80211-level channel validation fails
(e.g., combinations check, DFS, or no available radio),
drv_assign_vif_chanctx() is never reached. Since ath12k_mac_vdev_create()
is only called from that path, arvif->is_created remains false and
arvif->ar remains NULL for the failed link.
The subsequent drv_change_sta_links() call reaches
ath12k_mac_op_change_sta_links(), which allocates an arsta and sets
ahsta->links_map |= BIT(link_id) for the broken link before checking
whether the link is ready. When the vdev was never created, only
station_add() is skipped, but the link remains in links_map.
Any subsequent operation iterating links_map and dereferencing arvif->ar
without a NULL check will crash. Two observed examples are NULL deref in
ath12k_mac_ml_station_remove() on disconnect and in ath12k_mac_op_set_key()
when wpa_supplicant installs PTK keys.
BUG: Unable to handle kernel NULL pointer dereference at 0x00000000
pc : ath12k_mac_station_post_remove+0x40/0xe8 [ath12k]
Call trace:
ath12k_mac_station_post_remove+0x40/0xe8 [ath12k]
ath12k_mac_op_sta_state+0xb60/0x1720 [ath12k]
drv_sta_state+0x100/0xbd8 [mac80211]
__sta_info_destroy_part2+0x148/0x178 [mac80211]
ieee80211_set_disassoc+0x500/0x678 [mac80211]
BUG: Unable to handle kernel NULL pointer dereference at 0x00000000
pc : ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k]
Call trace:
ath12k_mac_op_set_key+0x1f8/0x2c0 [ath12k]
drv_set_key+0x70/0x100 [mac80211]
ieee80211_key_enable_hw_accel+0x78/0x260 [mac80211]
ieee80211_add_key+0x16c/0x2ac [mac80211]
nl80211_new_key+0x138/0x280 [cfg80211]
Fix this by checking arvif->is_created before calling
ath12k_mac_alloc_assign_link_sta(). This prevents the broken link from
entering links_map, so all subsequent operations iterating the bitmap
are protected. The reliability of arvif->is_created across all error
paths is ensured by the preceding patch.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
The firmware-controlled rsp->count field is used as the loop bound for
indexing into the flexible rsp->regs[] array without validation against
the message length. A count exceeding the actual data causes out-of-
bounds reads from the heap-allocated message buffer.
Add a check that count fits within the received message. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix NMI/tracepoint re-entry deadlock on lru locks
NMI and tracepoint BPF programs can re-enter the per-CPU or global
LRU lock that bpf_lru_pop_free()/push_free() already hold on the
same CPU, AA-deadlocking. Lockdep reports "inconsistent
{INITIAL USE} -> {IN-NMI}" on &l->lock (syzbot c69a0a2c816716f1e0d5)
and "possible recursive locking detected" on &loc_l->lock (syzbot
18b26edb69b2e19f3b33).
Prior trylock and rqspinlock based fixes (see links) were nacked
because compromised on reliability.
This patch converts every LRU lock site to rqspinlock_t and adds a
recovery path for some failure windows to avoid node leaks.
Failure recovery:
- *_pop_free top-level: return NULL; prealloc_lru_pop() already
treats that as no-free-element (-ENOMEM).
- Cross-CPU steal: skip the victim's locked loc_l, try next CPU.
- Post-steal local lock fail: publish stolen node to lockless
per-CPU free_llist; next pop on this CPU picks it up.
- push_free fail: mark node pending_free=1. __local_list_flush(),
__local_list_pop_pending() reclaim the node from pending_list.
__bpf_lru_list_shrink_inactive() reclaims the node from inactive
list. Nodes from active list are reclaimed by __bpf_lru_list_shrink()
or after __bpf_lru_list_rotate_active() demotes it to the inactive. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Fix recursive lock in device_cache_fw_images()
A recursive locking deadlock can occur in the firmware loader's power
management notification handler.
During system suspend or hibernation preparation, fw_pm_notify() calls
device_cache_fw_images(). This function acquires fw_lock to set the
firmware cache state to FW_LOADER_START_CACHE and then iterates over all
devices using dpm_for_each_dev() while still holding the lock.
For each device, dev_cache_fw_image() schedules asynchronous work to cache
the firmware. If memory allocation for the async work entry fails (e.g., in
out-of-memory conditions), async_schedule_node_domain() falls back to
executing the work function synchronously in the current thread.
The synchronous execution path (__async_dev_cache_fw_image() ->
cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire
fw_lock again. Since the current thread already holds fw_lock, this results
in a recursive locking deadlock.
Fix this by releasing fw_lock immediately after updating the cache state
and before calling dpm_for_each_dev(). The lock is only needed to protect
the state update. Concurrent firmware requests will correctly see the
FW_LOADER_START_CACHE state and use the piggyback mechanism, which is
independently protected by its own fwc->name_lock. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: Fix possible NULL pointer dereference in mt7996_mac_write_txwi_80211()
For injected frames (e.g. via radiotap), mac80211 can pass
info->control.vif = NULL, as explicitly noted in struct ieee80211_tx_info.
Check vif pointer before executing ieee80211_vif_is_mld() in
mt7996_mac_write_txwi_80211 routine in order to avoid a possible NULL
pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
vhost/net: complete zerocopy ubufs only once
vhost-net initializes one ubuf_info per outstanding zerocopy TX
descriptor and hands it to the backend socket. The networking stack may
then clone a zerocopy skb before all skb references are released. For
example, batman-adv fragmentation reaches skb_split(), which calls
skb_zerocopy_clone() and increments the same ubuf_info refcount.
vhost_zerocopy_complete() currently treats every ubuf callback as a
completed vhost descriptor. It dereferences ubuf->ctx, writes the
descriptor completion state, and drops the vhost_net_ubuf_ref even when
the callback only releases a cloned skb reference. A backend reset can
therefore wait for and free the vhost_net_ubuf_ref while another cloned
skb still carries the same ubuf_info. A later completion then
dereferences the freed ubufs pointer.
KASAN reports the stale completion as:
BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0
BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0
vhost_zerocopy_complete
skb_copy_ubufs
__dev_forward_skb2
veth_xmit
The freed object was allocated from vhost_net_ioctl() while setting the
backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend
removal, while delayed skb completion still reached
vhost_zerocopy_complete().
Honor the generic ubuf_info refcount before touching vhost state, and run
the vhost descriptor completion only for the final ubuf reference. This
matches the msg_zerocopy_complete() ownership rule for cloned zerocopy
skbs. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for non-serdev device
hu->serdev is NULL for hci_uart attached via non-serdev paths, but
qca_dmp_hdr() unconditionally dereferences hu->serdev->dev.driver->name,
causing a NULL pointer dereference.
Fix by guarding the dereference with a NULL check and falling back to
"hci_ldisc_qca" for the non-serdev case. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
When btmtk_isopkt_pad() fails, the previously allocated URB is not freed,
leaking the urb structure. Add usb_free_urb() before returning the error. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix FRMR set pinned push error path
Add destruction of FRMR handles in case the push to the pool fails.
This prevents resources leak in case pool page allocation fails. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: meson: aiu: Validate written enum values
The AIU HDMI and internal codec mux put callbacks use the written enum
value with snd_soc_enum_item_to_val() before checking whether the value is
valid for the enumeration.
Reject out-of-range values before converting the enum item, matching the
validation already done by the G12A HDMI and internal codec mux controls. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_flow: Dont expose folded kernel pointers
The flow classifier falls back to addr_fold() for fields that are missing
from packet headers. In map mode, userspace controls mask, xor, rshift,
addend and divisor, and can observe the resulting classid through class
statistics. This allows a tc classifier in a user/network namespace to
recover the 32-bit folded value of skb->sk, skb_dst() or skb_nfct().
Align with standard kernel practices for pointer hashing and replace the
XOR folding with a keyed siphash (which is cryptographically secure) |
| In the Linux kernel, the following vulnerability has been resolved:
net: pfcp: allocate per-cpu tstats for PFCP netdevs
PFCP uses dev_get_tstats64() as its ndo_get_stats64 callback, but
pfcp_link_setup() does not request NETDEV_PCPU_STAT_TSTATS. The net
core therefore leaves dev->tstats NULL for PFCP devices.
Creating a PFCP rtnetlink device can immediately ask the new netdev for
stats while building the RTM_NEWLINK notification. That reaches
dev_get_tstats64() and dereferences the NULL dev->tstats pointer.
Set pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS during PFCP link setup so
the net core allocates the storage expected by dev_get_tstats64(). |
