| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
IB/isert: reject login PDUs declaring more data than was received
isert_login_recv_done() records how many bytes the HCA actually placed in
the login buffer, but nothing compares that against the length the login
PDU's BHS declares. isert_rx_login_req() copies min(login_req_len,
MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then
reads the declared length back out of that buffer - for the first PDU in
iscsi_target_locate_portal(),
payload_length = ntoh24(login_req->dlength);
tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL);
and for the ones after it in iscsi_decode_text_input(), reached from
iscsi_target_do_login().
login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so
an initiator that declares more than it sends reads off the end of it,
before authentication and with the length under its control:
BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80
Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167
__asan_memcpy+0x23/0x60
kmemdup_nul+0x43/0x80
iscsi_target_locate_portal+0x48d/0x1180
iscsi_target_login_thread+0x19a9/0x3350
Allocated by task 167:
__kmalloc_cache_noprof+0x158/0x370
iscsi_target_login_thread+0x971/0x3350
which belongs to the cache kmalloc-8k of size 8192
allocated 8192-byte region
Falsifying the second login PDU instead reaches the other reader, on the
same buffer:
BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80
Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50
Workqueue: isert_login_wq iscsi_target_do_login_rx
__asan_memcpy+0x23/0x60
kmemdup_nul+0x43/0x80
iscsi_decode_text_input+0xc6/0x11c0
iscsi_target_do_login+0x261/0x1470
iscsi_target_do_login_rx+0x51d/0x7d0
iscsit over TCP is not exposed: iscsit_get_login_rx() validates the
declared length with iscsi_target_check_login_request() and then reads
exactly that many bytes off the socket, so the declared length governs
how much arrives rather than how much is copied out of an already-filled
buffer. isert does not call iscsi_target_check_login_request() at all.
Reject a login PDU whose declared DataSegmentLength exceeds what was
received, in both paths that reach isert_rx_login_req():
isert_get_login_rx() for the first login PDU and isert_login_recv_done()
for the ones after it. dlength <= login_req_len is allowed because the
received count can include up to three bytes of iSCSI padding.
Once the check is in place the copy out can no longer exceed the copy in:
the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot
exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is
login_req_len.
Like the existing short-PDU check added by 29e7b925ae6d, the reject in
isert_login_recv_done() returns without completing login_req_comp, so a
malformed subsequent PDU leaves the login to be torn down by the login
timer rather than failing immediately. The first-PDU path returns an
error and fails straight away.
Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an
initiator that sends the real key=value payload while declaring 8193 in
the BHS, on the first login PDU and on the second in separate runs. The
reported read size tracks the declared value exactly; 16384 and 61440
behave the same. Unpatched 3 of 3 runs report on each of the two paths,
patched 0 of 3 on both, run alternately in a single session, and a normal
login still completes on the patched build. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix return status of RMI log page on allocation failure
nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS
(set by the successful nvmet_req_find_ns() call) when the kzalloc() for
the log buffer fails. It then jumps to the out label and completes the
request with a success status, so the host is told the command succeeded
while no data was transferred.
Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler,
so an allocation failure is reported as an internal error. |
| In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request
__nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the
rsp_iu mapping fails, the original code only recorded the error and fell
through: it left the already-mapped cmd_iu unmapped and still marked the
op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call
.exit_request() when .init_request() fails, the cmd_iu mapping is leaked
for every op whose rsp_iu mapping fails.
Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and
returns the error without marking the op idle, so it stays in the
FCPOP_STATE_UNINIT state set by the initial memset(). |
| In the Linux kernel, the following vulnerability has been resolved:
spi: davinci: switch to managed controller allocation
The controller is allocated with the non-managed spi_alloc_host() while
the interrupt is registered with devm_request_threaded_irq(). During
removal, spi_bitbang_stop() only unregisters the controller; the
subsequent spi_controller_put() then frees the controller together with
its embedded davinci_spi devdata, which is the IRQ handler's dev_id.
The devm_request_threaded_irq() release action (free_irq()), which
drains the handler, does not run until after .remove() returns. A late
or latched interrupt can therefore reach davinci_spi_irq() and
dereference already-freed memory.
Switch to devm_spi_alloc_host() so that the devres LIFO order releases
the controller only after free_irq() has drained the handler, and drop
the now-redundant spi_controller_put() from .remove(). The probe error
path is simplified to direct returns.
The clock is acquired with devm_clk_get_enabled(), which is registered
after the IRQ and thus released before it by the devres LIFO order.
Drain the interrupt explicitly with devm_free_irq() before disabling the
controller so that a late interrupt cannot access the registers of a
clock-gated controller.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Add vm_bind region with kbo range overlap check
When a VM is created, caller has to specify the range of the address space
carve-out set aside for mapping kernel BO's. That means vm_bind mappings of
UM-exposed BO's should not intersect with that region, but at the moment
we're not checking this.
At first, I thought of giving these values to drm_gpuvm_init() through its
reserve_{offset, range} arguments, but it turns out that is meant for VM
address spans that are not managed through the usual drm_gpuvm split/merge
circuit, so storing the end of the user VA range at VM creation time and
doing a quick check in the vm_bind ioctl path was the simplest workaround.
The new check also makes sure vm_bind range doesn't overflow the size of a
64-bit unsigned integer. That was already being done further down the call
stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to
fail early in the driver before GPUVM functions are invoked so that we
won't waste time allocating vm_bind context resources. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix overreads in ath12k_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 ath12k_wmi_tlv_data_len() to recover the payload
length of a parsed TLV from the header preceding its data pointer. Use it
in ath12k_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:
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. |
