IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier
mlx5_ib_alloc_transport_domain() allocates a transport domain and then
may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.
Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an
error. Also return 0 explicitly in the no-loopback-capability success
branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().
RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure
mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with
mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path
through mlx5r_umr_unmap_free_xlt().
After mlx5_odp_populate_xlt() became fallible, its error path returned
directly and skipped that cleanup. This leaks the XLT DMA mapping and
buffer. If the emergency XLT page was used, it also leaves
xlt_emergency_page_mutex locked.
Break out of the loop so execution falls through the existing cleanup path.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference
MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list
before initializing the fields used by the shared error path.
If eventfd_ctx_fdget() then fails, the unwind path dereferences
event_sub->ev_file in uverbs_uobject_put() and calls
subscribe_event_xa_dealloc() with an unset xa_key_level1.
subscribe_event_xa_alloc() creates the XA entry exactly once for a given
key_level1, on the first occurrence of that key. The unwind path must
therefore call subscribe_event_xa_dealloc() exactly once for it as wel
RDMA/srpt: fix integer overflow in immediate data length check
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: fix integer overflow in immediate data length check
imm_buf->len is a user-controlled uint32_t received from the network.
Adding it to imm_data_offset without overflow checking allows a
malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap
around to a small value, bypassing the bounds check, and subsequently
passing a ~4GB length to sg_init_one().
Use check_add_overflow() to detect wrapping before the comparison.
drm/syncobj: Fix memory leak in drm_syncobj_find_fence()
In the Linux kernel, the following vulnerability has been resolved:
drm/syncobj: Fix memory leak in drm_syncobj_find_fence()
Commit 18226ba52159 ("drm/syncobj: reject invalid flags in
drm_syncobj_find_fence") forgot to take into account the fact that
drm_syncobj_find() takes a reference to syncobj and returns early
without dropping the reference, leading to memory leaks.
Reported by: Sam Spencer <[email protected]>
In the Linux kernel, the following vulnerability has been resolved:
dm: limit target bio polling to one shot
dm_poll_bio() is the ->poll_bio() callback for a stacked dm device.
The caller only knows about the dm queue, so it may decide to do a
spinning poll if it thinks a single queue is being polled. Passing those
flags unchanged to the mapped clone lets blk_mq_poll() spin on a target
queue from inside dm_poll_bio().
With io_uring IOPOLL on a dm-stripe target this can keep a task in
dm_poll_bio() -> bio_poll() -> blk_mq_poll()
long enough to trigger an RCU CPU stall, before io_uring gets back to
io_iopoll_check() and its need_resched(
tracing: Bound synthetic-field strings with seq_buf
In the Linux kernel, the following vulnerability has been resolved:
tracing: Bound synthetic-field strings with seq_buf
The synthetic field helpers build a prefixed synthetic variable name and
a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The
current code appends those strings with raw strcat(), so long key lists,
field names, or saved filters can run past the end of the staging
buffers.
Build both strings with seq_buf and propagate -E2BIG if either the
synthetic variable name or the generated command exceeds
MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while
using the helper intended for bounded command c
RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs
The irdma_copy_user_pgaddrs function loops through all of the umem DMA
blocks to populate the PBLEs and will stop when either the last DMA
block is reached or palloc->total_cnt is reached. The issue is that
the logic for checking palloc->total_cnt would only work for non-zero
values.
When irdma_setup_pbles is called with lvl==0, it
calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means
the only way to break out of the loop is to reach the last umem DMA
block, which means it could end up going beyo
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix log flood after cmd_mbox failure
hns_roce_cmd_mbox() is the command interface between driver and
hardware. When hardware is abnormal, the unlimited error printings
after hns_roce_cmd_mbox() failure will cause log flood and even
system crash.
Replace ibdev_err() and ibdev_warn() with their ratelimited versions
in the error handling path after hns_roce_cmd_mbox() (and its wrappers
hns_roce_create_hw_ctx/hns_roce_destroy_hw_ctx) fails.
ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data
The OSS sequencer processes the input MIDI bytes into a sequencer
event to be dispatched later (in snd_seq_oss_midi_putc() called from
snd_seq_oss_process_event()). When it's a SysEx data, the event
record contains data.ext.ptr pointer to the original SysEx bytes, and
the referred data is copied into the pool afterwards at dispatching.
The problem is that, if the sequencer port gets closed concurrently
before the dispatch, the OSS sequencer core also releases the
resources (in snd_seq_oss_midi_check_exit_p
ALSA: seq: midi: Serialize output teardown with event_input
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 ru
nvmet-tcp: fix page fragment cache leak in error path
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, whi
nvmet-tcp: check return value of nvmet_tcp_set_queue_sock
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: check return value of nvmet_tcp_set_queue_sock
The return value of nvmet_tcp_set_queue_sock() is currently ignored in
nvmet_tcp_tls_handshake_done(). If it fails (e.g., due to the socket
not being in TCP_ESTABLISHED state), the socket callbacks will not be
properly set, leading to queue and socket leakage.
Fix this by capturing the return value and calling
nvmet_tcp_schedule_release_queue() on failure to ensure proper cleanup.
nvme-multipath: fix flex array size in struct nvme_ns_head
In the Linux kernel, the following vulnerability has been resolved:
nvme-multipath: fix flex array size in struct nvme_ns_head
struct nvme_ns_head contains a flexible array member, current_path[],
which is indexed using the NUMA node ID:
head->current_path[numa_node_id()]
The structure is currently allocated as:
size = sizeof(struct nvme_ns_head) +
(num_possible_nodes() * sizeof(struct nvme_ns *));
head = kzalloc(size, GFP_KERNEL);
This allocation assumes that NUMA node IDs are sequential and densely
packed from 0 .. num_possible_nodes() - 1. While this assumption holds
on many systems, it is not always true on some architectures s
nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix out-of-bounds access in nvme_setup_descriptor_pools
nvme_setup_descriptor_pools() indexes dev->descriptor_pools[] using the
numa_node forwarded from hctx->numa_node by its single caller,
nvme_init_hctx_common(). On a non-NUMA kernel hctx->numa_node is
NUMA_NO_NODE (-1). Because the parameter was declared 'unsigned', the
value becomes UINT_MAX and the index walks off the array (sized to
nr_node_ids), faulting during nvme_alloc_ns() and leaving the namespace
without a /dev node.
Reproduces on any NVMe controller probed by a CONFIG_NUMA=n kernel:
BUG: unabl
net/sched: cls_bpf: prevent unbounded recursion in offload rollback
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_bpf: prevent unbounded recursion in offload rollback
Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd().
Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the
bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace
calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then
swaps prog/oldprog and recursively calls itself to roll back. But
bpf_tc_accept=0 makes the rollback fail too, which triggers yet another
rollback frame with the same arguments, and so on until the stack is
exhausted.
bpf_tc_accept is just a c
gpu: host1x: Allow entries in BO caches to be freed
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Allow entries in BO caches to be freed
When a buffer object is pinned via host1x_bo_pin() with a cache, the
resulting mapping is kept in the cache so it can be reused on subsequent
pins. Each mapping held a reference to the underlying host1x_bo (taken
in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached,
the bo itself could not be freed.
However, the only way to remove the cached mapping was through the free
path of the buffer object. This meant that if a bo got cached, it could
never get freed again.
Resolve the circularity by holding a weak
gpu: host1x: Fix iommu_map_sgtable() return value check
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix iommu_map_sgtable() return value check
Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.
pin_job() also was incorrectly assigning to 'int', which could cause
overflows into negative values.
Update pin_job() to correctly check for errors from iommu_map_sgtable.
dax/kmem: account for partial discontiguous resource upon removal
In the Linux kernel, the following vulnerability has been resolved:
dax/kmem: account for partial discontiguous resource upon removal
When dev_dax_kmem_probe() partially succeeds (at least one range is
mapped) but a subsequent range fails request_mem_region() or
add_memory_driver_managed(), the probe silently continues, ultimately
returning success, but with the corresponding range resource NULL'ed out.
dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if
the underlying resource exists. When remove_memory() is called later, it
returns 0 because the memory was never added which causes
dev_dax_kmem_remove() to incorrec
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.