| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event()
There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so
the parse infrastructure does not enforce a minimum length for the event
struct. Additionally, the num_vdevs field is taken directly from firmware
and used as a loop bound over the vdev_ids array without checking that it
fits within the TLV payload. Either condition can cause an out-of-bounds
read.
Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so
the parse infrastructure enforces a minimum length for the fixed-size event
struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload
length of a parsed TLV from the header preceding its data pointer. Use it
in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before
the loop.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
media: qcom: iris: handle runtime PM resume failure in core deinit
Check the return value of pm_runtime_resume_and_get() in
iris_core_deinit().
If runtime PM resume fails, skip hardware power-off operations but
still perform software teardown and state transition. Also skip the
corresponding pm_runtime_put_sync() call to avoid unbalanced runtime
PM references. |
| In the Linux kernel, the following vulnerability has been resolved:
media: stm32: dcmi: fix some error handling bugs in probe()
There are a few issues here:
1) After we assign:
chan = dma_request_chan(&pdev->dev, "tx");
Then the error paths need to clean up before returning. The first
error path does a direct return.
2) The error paths check "dcmi->mdma_chan" but that is not assigned
until later so it results in memory leaks. Test "mdma_chan"
instead.
3) The error handling calls dma_release_channel(dcmi->dma_chan) before
"dcmi->dma_chan" has been assigned which leads to a NULL pointer
dereference. Use the "chan" variable instead.
I also moved the call to dma_release_channel() after the call to
dma_release_channel() so it mirrors the allocation code better. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_debugfs: Unregister panic notifier
cros_ec_debugfs_probe() registers notifier_panic with the EC panic
notifier chain. The remove path tears down debugfs and the console log,
but leaves the notifier registered. A later panic notification can call
back into the removed instance and queue work that accesses released
data.
Unregister the panic notifier before tearing down the debugfs and
console log state.
This issue was found by a static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: pci: fix error path in rtl_pci_probe()
In the last error path in rtl_pci_probe(), the cleanup functions are
skipped due to a wrong goto label. Moreover, the successful call to
rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to
be reverted. Fix this issue by updating the labels and adding the
relevant cleanup functions to the last error path. |
| In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Fix controller cleanup on EDL sysfs failure
mhi_register_controller() adds the controller device before creating the
optional trigger_edl sysfs file. If sysfs_create_file() fails, the error
path only drops the device reference and leaves the device registered.
Hence, call device_del() in the error path before put_device(). |
| In the Linux kernel, the following vulnerability has been resolved:
md: remove REQ_NOWAIT support from raid1/10/456
REQ_NOWAIT support in md personalities that can block internally is
fundamentally incomplete. While reads can avoid some blocking paths,
write requests can still encounter cases where one mirror succeeds while
another returns -EAGAIN. At that point md cannot distinguish queue
pressure from a real device failure, so it can neither record a bad
block nor safely retry the write without REQ_NOWAIT, leaving mirrors
with divergent data.
Rather than continue advertising REQ_NOWAIT support for personalities
that cannot implement it correctly, remove it from raid1, raid10 and
raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to
their underlying devices; stacked limits will still clear the feature if
any component device lacks REQ_NOWAIT support. |
| In the Linux kernel, the following vulnerability has been resolved:
md: recheck spare changes before starting sync
remove_spares() and remove_and_add_spares() modify the array's rdev
configuration. These operations are only safe after the array has been
suspended.
md_start_sync() checks whether spare configuration changes are needed
before taking reconfig_mutex. However, the rdev state can change before
the mutex is acquired, so the initial check can become stale. In that
case, md_choose_sync_action() may remove or replace rdevs while normal
I/O is still accessing them.
The race can occur as follows:
raid10d Worker Normal IO
____________ _______________________ ______________________
raid10_write_request()
wait_blocked_dev()
set Blocked
set Faulty
Skip Faulty rdev
rrdev->nr_pending++
.repl_bio = bio
removeable_rdev = false .
array not suspended .
lock mddev goto err_handle
lock mddev (wait)
.
update sb .
clear Blocked .
.
unlock mddev .
lock mddev (acquires)
remove_spares()
removeable_rdev = true
raid10_remove_disk()
rdev = replacement
replacement = NULL
rdev_dec_pending(NULL)
unlock mddev (NULL)->nr_pending--
In this case, rdev_dec_pending() is called with a NULL pointer,
resulting in a NULL pointer dereference when attempting to decrement
nr_pending.
Fix this by suspending the array when spare configuration changes are
needed, including for non-read-write arrays, and checking again after
taking reconfig_mutex. If the array was not already suspended and a
change is now needed, release the mutex, suspend the array, and
reacquire the mutex before continuing. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix stride mismatch in mac_phy_caps_parse()
Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the
mac_phy_caps buffer as tot_phy_id * len, where len is clamped to
min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The
subsequent memcpy() destination advances by sizeof(full struct) per slot
via C pointer arithmetic, not by the clamped len. When firmware sends
short TLVs, the second and later slots are written past the end of the
allocation.
The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the
buffer with full-struct pointer arithmetic, so the allocation must match
that stride.
Fix by using kzalloc_objs(), which derives the element size from the
pointer type, making allocation size and pointer stride provably
consistent regardless of what len the firmware provides.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()
Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the
mac_phy_caps buffer as tot_phy_id * len, where len is clamped to
min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent
memcpy() destination advances by sizeof(full struct) per slot via C
pointer arithmetic, not by the clamped len. When firmware sends short
TLVs, the second and later slots are written past the end of the
allocation.
The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the
buffer with full-struct pointer arithmetic, so the allocation must match
that stride.
Fix by using kzalloc_objs(), which derives the element size from the
pointer type, making allocation size and pointer stride provably
consistent regardless of what len the firmware provides.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published
In qcom_scm_probe(), devm_request_threaded_irq() is called before
smp_store_release(&__scm, scm). Two paths can dereference __scm before
it is published, both causing a NULL pointer dereference.
The IRQ handler receives scm via its data argument but passes only wq_ctx
to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then
dereference __scm directly. Thread scm through both functions so the IRQ
handler path never touches __scm.
Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via
qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing
qcom_scm_wait_for_wq_completion() to run before __scm is published and
dereference it. Add platform_set_drvdata(pdev, scm) early in probe and
change qcom_scm_wait_for_wq_completion() to take the device pointer and
use dev_get_drvdata() to reach scm, removing any dependency on __scm. |
| In the Linux kernel, the following vulnerability has been resolved:
block: fix dio leak on metadata mapping error
A failed integrity mapping holds a dio reference, so we need to go
through the full bio ending in case there were previously submitted
bio's in the sequence. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: isp1704_charger: cancel work on remove
The USB notifier and initial VBUS detection can schedule isp->work. The
remove path unregisters the notifier and power supply, but does not wait
for queued or running work before tearing down the power supply state.
Cancel the work after unregistering the notifier. Do this before
unregistering the power supply.
This issue was found by a static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: sc2731_charger: cancel work on remove
The USB notifier and initial charger detection can schedule info->work.
The remove path unregisters the notifier, but does not cancel queued or
running work before the devm-allocated driver data is released.
Set the platform drvdata used by remove, then cancel the work after
unregistering the notifier.
This issue was found by a static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix potential UAF in bpf_netns_link_update_prog
In bpf_netns_link_update_prog, the checks for old_prog and prog type
are currently performed locklessly before acquiring netns_bpf_mutex.
This creates a race condition that can lead to a UAF issue.
If two threads concurrently execute BPF_LINK_UPDATE on the same netns
link, the following execution path can trigger a UAF:
CPU0 CPU1
bpf_netns_link_update_prog
if (old_prog && old_prog != link->prog)
return -EPERM;
bpf_netns_link_update_prog
if (old_prog && old_prog != link->prog)
...
old_prog = xchg(&link->prog, new_prog);
bpf_prog_put(old_prog);
if (new_prog->type != link->prog->type) <-- trigger UAF
Fix this by moving the old_prog and prog->type checks inside the
netns_bpf_mutex critical section. Meanwhile, use guard() to simplify
lock management and avoid all the goto jumping. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix potential UAF when reading bpf link info
In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is
accessed without holding any locks. If the prog is concurrently replaced
via bpf_link_update, the old prog can be freed, leading to a potential
UAF issue.
Fix this by accessing link->prog under RCU protection to safely fetch
the pointer and guarantee its lifetime while reading its fields. |
| In the Linux kernel, the following vulnerability has been resolved:
lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone
dmirror_fault() is called from the dmirror_read() and dmirror_write()
retry loops after dmirror_do_read() or dmirror_do_write() finds a missing
device page table entry.
If the mirrored mm has already exited, mmget_not_zero() fails. The
current code returns 0 in that case, which tells the caller that faulting
succeeded even though no page was faulted and no device page table entry
was installed. The caller then retries the same address, hits -ENOENT
again, and can loop forever without making progress.
Return -EFAULT instead, so the ioctl fails when the mirrored mm is no
longer faultable. |
| In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: resume array on backlog_store() error path
backlog_store() suspends the array before checking whether a write-mostly
device exists. If no such device exists, the error path only unlocks
reconfig_mutex and leaves the array suspended, blocking subsequent I/O.
Use mddev_unlock_and_resume() to release both states. |
| In the Linux kernel, the following vulnerability has been resolved:
md: scope memalloc_noio to allocation critical sections
Storing a memalloc_noio_save() token in mddev->noio_flags lets one task
save the token and another task restore it. With concurrent suspend sysfs
writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in
that scope, and later task B can restore A's saved token.
Avoid tying the token lifetime to mddev. Keep mddev_suspend() and
mddev_resume() only responsible for array suspension, and enter
PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array
has been suspended. Restore the token before resuming the array.
A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent
workers and checks each worker's /proc/self/stat flags before and after the
sysfs write. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Check atomic pool allocation result directly
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(),
which returns the allocated page and fills cpu_addr only on success.
Do not rely on cpu_addr to detect allocation failure in this path. Check
the returned page directly before using it for the IOMMU mapping. |
