IB/isert: post the full-feature receive buffers after session registration
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: post the full-feature receive buffers after session registration
isert_put_login_tx() posts the full-feature receive buffers before
__transport_register_session() runs, so an initiator that does not wait
for the final Login Response can still have a SCSI command executed
against an se_session whose se_tpg is NULL - the same oops as the
previous patch, at target_submit+0xbe.
Post them from isert_get_rx_pdu(), which the previous patch already uses
to send that response, and post them before that send: the receive queue
is filled at the moment the initiator is told
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix use-after-free in siw_accept()
siw_accept() looks up the QP supplied by userspace. If that QP is
already in RTS, the function jumps to error cleanup before associating
the incoming CEP with it.
The cleanup tests whether qp->cep is non-NULL and assumes the current
call installed the association. However, qp->cep can point to the CEP
of an existing connection. The cleanup then drops a reference from the
incoming cep, not qp->cep. Once the incoming endpoint loses its
remaining references, this can free it before the subsequent cep->qp
store, causing a use-after-
module/dups: Fix use-after-free in kmod_dup_req lifetime handling
In the Linux kernel, the following vulnerability has been resolved:
module/dups: Fix use-after-free in kmod_dup_req lifetime handling
The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed
only after it is no longer referenced. When releasing an instance, the
kmod_dup_request_delete() function removes the kmod_dup_req from the
dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it.
However, this doesn't work correctly because parallel users referencing the
instance in kmod_dup_request_exists_wait() don't enter an RCU read-side
critical section. This can result in a use-after-free.
The kmod_dup_request_exi
In the Linux kernel, the following vulnerability has been resolved:
arm64: hibernate: Restore DAIF state on error
Sashiko AI has reported that if swsusp_mte_save_tags() for some reason
fails we return from swsusp_arch_suspend() with DAIF being masked -
that is not what we'd expect. Restore the saved DAIF state before
returning from the error path.
drm/amd/display: Resize MST HDCP per-connector arrays to 32
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Resize MST HDCP per-connector arrays to 32
AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of
32 connectors. But the way it's used is like MAX_DISPLAY_COUNT.
Hence we're off by one with DRM core, which supports a max of 32
connectors.
Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT
to match its actual use, and increase the size to 32 to match the
originally intended size.
phy: sunplus: fix error handling in sp_uphy_init()
In the Linux kernel, the following vulnerability has been resolved:
phy: sunplus: fix error handling in sp_uphy_init()
Fix the error paths of sp_uphy_init() to undo exactly what each stage
did: return directly if clk_prepare_enable() fails, release only the clock
if reset_control_deassert() fails, and jump to err_reset if
update_disc_vol() fails so the clock and reset are not leaked.
drm/amdgpu/gfx6: Use PFP on the compute queues too
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx6: Use PFP on the compute queues too
On GFX6, the compute rings use the same CP path as
the graphics ring. The only difference is that they
don't support draw commands. (As opposed to GFX7 and
newer which have a separate command parser that is
called MEC for compute queues.)
This means that we have to take into consideration
that the PFP also exists on compute queues on GFX6:
Use PFP for register writes on both graphics and
compute queues.
In the pipeline sync, use the PFP to wait for the
previous fence (and not the ME) to prevent the PFP
from starting to e
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path
qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time
after releasing optrom_mutex. The repeated read is redundant and, unlike
the first, runs without optrom_mutex held, exposing flash access to
concurrent optrom operations. Drop the duplicate call.
firmware_loader: do not queue completed sysfs fallback requests
In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: do not queue completed sysfs fallback requests
fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to
pending_fw_head. device_add() publishes the fallback loading interface, so
a userspace helper which discovers the device by scanning sysfs can write 0
to the loading attribute and complete the request before it is queued as
pending.
In that interleaving firmware_loading_store() calls fw_state_done() while
pending_list still points to itself, so it cannot remove an entry from
pending_fw_head. The subsequent unconditional list_add() then qu
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: release subpool on fill_super failure
hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size
mount options are specified. hugepage_new_subpool() may also reserve huge
pages for min_size.
If root dentry creation fails after the subpool is created, the failure
path frees the subpool with kfree(). This bypasses hugepage_put_subpool()
and can leave min_size reservations charged.
Use hugepage_put_subpool() on the failure path, matching the normal
put_super path.
phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
This can also happen if user re-enables runtime-pm via the sysfs
attribute before qmp phy is initialized.
Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
variable that can be used to avoid relyin
phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
Runtime PM must be enabled before creating the PHY, since phy_create()
only enables runtime PM on the PHY device if it is already enabled on
this parent device. However, the runtime PM callbacks dereference the
hsphy instance, which is not yet ready, leaving a window where a suspend
callback may trigger a NULL pointer dereference.
Take a runtime PM usage reference with pm_runtime_get_noresume() before
enabling runtime PM and release it once the PHY has been created, so that
no runtime suspend can ru
phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
This can also happen if user re-enables runtime-pm via the sysfs
attribute before qmp phy is initialized.
Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
variable that can be used to avoid relying on th
md/raid5: round bitmap stripes with sector division
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: round bitmap stripes with sector division
raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe
widths before converting it to component sectors. That width is
chunk_sectors multiplied by the number of data disks, and it is not
always a power of two.
Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks.
The full-stripe width is 3072 sectors. For a one-sector write at array
sector 3072, correct rounding gives array range [3072, 6144), which maps
to component range [1024, 2048). The old round_down()/round_up() logic
instead gives
md/raid1: don't set array_frozen in raid1_takeover()
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: don't set array_frozen in raid1_takeover()
raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated
r1conf and nothing ever clears it, so every I/O to the array stalls
permanently once _wait_barrier() sees it stuck at 1.
This used to be harmless: level_store() called mddev_resume() right
after pers->run(), which called raid1_quiesce(mddev, 0) and cleared
array_frozen back to 0 regardless of what raid1_takeover() set. Commit
b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that
quiesce(mddev, 0) call, so the pre-set now sticks.
setup_conf(
coresight: etm4x: fix underflow for usage of (nrseqstate - 1)
In the Linux kernel, the following vulnerability has been resolved:
coresight: etm4x: fix underflow for usage of (nrseqstate - 1)
According to IHI006H Embedded Trace Macrocell Architecture
Specification[0], TRCSEQEVR<n> is implemented only when
TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2;
otherwise, TRCIDR5.NUMSEQSTATE is 0b000.
IOW, the number of usage in the initialisation or setting
TRCSEQEVR<n> with drvdata->nrseqstate - 1 in the loop could make
underflow issue when TRCIDR5.NUMSEQSTATE is 0b000.
Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate.
As part of this introduce ETM_MAX_SEQ_TRANSITIONS
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
In the Linux kernel, the following vulnerability has been resolved:
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
In the perf enable path, there are missing cases where
cscfg_csdev_disable_active_config() is not called:
- Branch broadcast is selected but not supported by the hardware
- etm4_enable_hw() fails
This can lead to a leak of config_desc->active_cnt.
Fix this by properly calling cscfg_csdev_disable_active_config()
in these error paths.
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails
In the Linux kernel, the following vulnerability has been resolved:
scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails
sd_set_special_bvec() allocates a special payload page for UNMAP and
WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in
sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI
midlayer does not call uninit_command() because RQF_DONTPREP is not set
yet, leaking the page.
Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after
freeing the page.
btrfs: defrag: fix deadlock between defrag and delalloc space reservation
In the Linux kernel, the following vulnerability has been resolved:
btrfs: defrag: fix deadlock between defrag and delalloc space reservation
While running fsstress with autodefrag and flushoncommit, hit a deadlock
due to the fact that defrag reserves delalloc space while it's holding
dirty and locked folios, besides the extent range lock. The stack traces
are the following:
[958.624] task:kworker/u50:3 state:D stack:0 pid:20365 tgid:20365 ppid:2 task_flags:0x4208060 flags:0x00080000
[958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[958.627] Call Trace:
[958.628] <TASK>
[958.628] __
btrfs: always wait for ordered extents to avoid OE races
In the Linux kernel, the following vulnerability has been resolved:
btrfs: always wait for ordered extents to avoid OE races
[BUG]
Syzbot reported a bug that there can be conflicting OEs for the same
range:
BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[ 179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384