misc: ad525x_dpot: use driver core groups for sysfs files
In the Linux kernel, the following vulnerability has been resolved:
misc: ad525x_dpot: use driver core groups for sysfs files
ad_dpot_probe() creates per-RDAC sysfs files manually and then
optionally creates the command sysfs group. This leaves probe responsible
for rolling back partial sysfs state and makes remove responsible for
matching every file that probe created.
Move the device attributes into driver core dev_groups for the I2C and
SPI drivers and use an is_visible() callback to expose only the
attributes supported by the probed device. With this shape, the driver
core creates the sysfs files only after probe succeeds and removes t
ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove
Three issues arise when the device is removed while a tty session is
still active:
1. UAF of struct ipoctal: the remove callback frees ipoctal via
kfree() while tty ops may still access it. Fix by introducing
kref-based lifetime management — kref is taken in install() when
a tty is opened and released in cleanup() when the tty is finally
destroyed; remove() uses kref_put() instead of kfree().
2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove()
frees xmit_buf via tty
In the Linux kernel, the following vulnerability has been resolved:
mtd: mtdswap: Avoid freeing registered blktrans device twice
In mtdswap_add_mtd(), debugfs setup failure after successful blktrans
registration can free mbd_dev twice.
add_mtd_blktrans_dev() initializes the blktrans device reference and
publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the
disk down and drops the blktrans reference; when that reference reaches
zero, blktrans_dev_release() frees the mtd_blktrans_dev.
The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell
through the common cleanup label and called kfree(mbd_dev) again.
mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()
In the Linux kernel, the following vulnerability has been resolved:
mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()
mtd_add_partition() does not reject the special offset value
MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in
add_mtd_device() when called through the BLKPG ioctl on NAND
devices. The RETAIN value depends on cur_offset being the end of
the previous partition, but in the dynamic partition path
cur_offset equals the offset argument itself, causing undefined
behavior.
Commit 5daa7b21496a ("mtd: prepare partition add and del functions
for ioctl requests") introduced mtd_add_partition() and correctly
rejected MTDPA
drm/v3d: Associate BOs with every job that accesses them
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Associate BOs with every job that accesses them
A submission can expand into a chain of jobs (e.g. bin + render + cache
clean). Implicit synchronization in v3d_submit_lock_reservations() is gated
on each job's bo[], but the BO list was only ever attached to the last job
of the chain. When that last job is a trailing CACHE_CLEAN job, the job
that actually consumes the BOs (that is, a RENDER or CSD job) was left with
bo_count == 0 and picked up no implicit dependencies. It could therefore
be dispatched to the hardware and read a BO while another context was still
wri
software node: Fix software_node_get_reference_args() with index -1
In the Linux kernel, the following vulnerability has been resolved:
software node: Fix software_node_get_reference_args() with index -1
The bounds check for the index passed to
software_node_get_reference_args() was failing when passed UINT_MAX,
this in turn would lead to an out of bound access in the property
array. Fix the bound check to also cover the UINT_MAX case.
dmaengine: dw-edma: Terminate all descriptors without callbacks
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw-edma: Terminate all descriptors without callbacks
The DMA Engine client documentation says in the "Terminate APIs" section
of Documentation/driver-api/dmaengine/client.rst:
"No callback functions will be called for any incomplete transfers."
dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches
the interrupt handler. This schedules a callback for the active descriptor
and leaves other issued or submitted descriptors queued. A late callback
after dmaengine_terminate_sync() can dereference client state that has
already been freed, while le
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw-edma: Serialize abort state updates
dw_edma_abort_interrupt() drops vc.lock before changing request and
status. issue_pending() can acquire the lock in that small window,
observe the old busy state, and skip starting queued descriptors. Then
the abort handler overwrites the channel status as idle, leaving the new
descriptors stranded for good.
Keep descriptor completion and the state transition in the same critical
section.
dmaengine: dw-edma: Serialize channel state checks
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw-edma: Serialize channel state checks
pause() and resume() read and update channel state without holding vc.lock,
while the interrupt handlers update the same state under it. Take the same
lock around those state checks so that request, status, and configured stay
consistent.
For example, pause() can observe EDMA_ST_BUSY right before the interrupt
handler completes the final descriptor and moves the channel to
EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No
further interrupt will acknowledge the request, and since issue_pending()
re
ASoC: meson: Keep link pointers valid on realloc failure
In the Linux kernel, the following vulnerability has been resolved:
ASoC: meson: Keep link pointers valid on realloc failure
meson_card_reallocate_links() grows the DAI link and private data
arrays with two consecutive krealloc() calls and updates the owner
pointers only after both calls have succeeded.
A successful krealloc() may move the data: it frees the old block and
returns a new one. When that happens for the link array and the second
krealloc() then fails, card->dai_link still points to the block that
krealloc() already freed, and the error path frees the new block too.
The probe error path then calls meson_card_clean_references(),
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Propagate sdma_txinit_ahg() errors
set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg().
If sdma_txinit_ahg() fails, it returns before initializing tx->txreq.
However, set_txreq_header_ahg() ignores the error and returns the AHG
change count, causing the caller to continue processing the request as
though initialization had succeeded.
Propagate sdma_txinit_ahg() failures to the caller and abort request
processing when initialization fails.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]
For a user QP, qp->sq.queue is a ring the application writes directly,
so rxe_post_send() takes the is_user branch and only schedules send_task
without validating the WQE. rxe_requester() consumes it in place via
req_next_wqe() and calls copy_data(), which indexes
&wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge.
Only the kernel path bounds num_sge (validate_send_wr()); the user WQE
is never checked, so a local unprivileged user can post a WQE with an
out-of-range cur_sge or oversized num_s
irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()
When its_irq_gic_domain_alloc() fails, the following
its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the
corresponding interrupt, which leaks the resource.
Invoke its_vpe_teardown() in the error handling path to avoid the leak.
[ tglx: Massaged change log ]
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: validate MADT IOAPIC entry bounds
The IOAPIC hotplug lookup parses both MADT and _MAT records directly.
The MADT walk previously used a subtable's declared length to advance
the cursor after only locating a generic header. The _MAT path likewise
passed a generic header to the IOAPIC helper.
Validate that a current record has a complete generic header, that its
declared length is contained in the available record range, and that a
typed IOAPIC record contains the full fixed IOAPIC body before reading
its fields. Use the same relation for both MADT and _MA
ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root
acpi_pci_root_add() assigns the freshly allocated root to
device->driver_data before dmar_device_add() and pci_acpi_scan_root().
Both failure paths reach the end: label where root is kfree()'d, but
only the pci_acpi_scan_root() path clears driver_data first.
When dmar_device_add() fails during a hot-add, root is freed while
device->driver_data still points at it. The ACPI core does not clear
driver_data on attach failure, so a later acpi_pci_find_root() call may
dereference this dangling pointer.
acpi_
In the Linux kernel, the following vulnerability has been resolved:
bpf: Zero queue and stack outputs on lock failure
Queue and stack pop/peek helpers accept an uninitialized output buffer
because the verifier expects the helper to initialize it. The empty-map
error path clears the buffer, but a failed lock acquisition returns
-EBUSY without writing it.
Clear the output before returning -EBUSY so BPF programs cannot observe
uninitialized stack contents after a failed helper call.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix use after free in ib_query_qp()
When querying a QP via the netlink flow the only synchronization
mechanism for the said QP is rdma_restrack_get(), meanwhile during the
QP destroy path rdma_restrack_del() is called at the end of the
ib_destroy_qp_user() function which is too late, since by then the
vendor specific resources for said QP would already be destroyed, and
till the rdma_restrack_del() is called this QP can still be accessed,
which could cause the use after free below.
Fix this by moving the rdma_restrack_begin_del() to the start of the
ib_destroy_q
RDMA/core: Fix potential use after free in ib_destroy_cq_user()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix potential use after free in ib_destroy_cq_user()
When accessing a CQ via the netlink path the only synchronization
mechanism for the said CQ is rdma_restrack_get().
Currently, rdma_restrack_del() is invoked at the end of
ib_destroy_cq_user(), which is too late, since by that point
vendor-specific resources associated with the CQ might already be
freed. This can leave a short window where the CQ remains accessible
through restrack, leading to a potential use-after-free.
Fix this by moving the rdma_restrack_begin_del() call to the start of
ib_destroy_cq_user()
RDMA/core: Fix potential use after free in ib_destroy_srq_user()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix potential use after free in ib_destroy_srq_user()
When accessing a SRQ via the netlink path the only synchronization
mechanism for the said SRQ is rdma_restrack_get().
Currently, rdma_restrack_del() is invoked at the end of
ib_destroy_srq_user(), which is too late, since by that point
vendor-specific resources associated with the SRQ might already be
freed. This can leave a short window where the SRQ remains accessible
through restrack, leading to a potential use-after-free.
Fix this by moving the rdma_restrack_begin_del() call to the start of
ib_destroy_srq
RDMA/core: Fix potential use after free in counter_release()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix potential use after free in counter_release()
When accessing a counter via the netlink path the only synchronization
mechanism for the said counter is rdma_restrack_get().
Currently, rdma_restrack_del() is invoked at the end of
counter_release(), which is too late, since by that point
vendor-specific resources associated with the counter might already be
freed. This can leave a short window where the counter remains
accessible through restrack, leading to a potential use-after-free.
Fix this by moving the rdma_restrack_del() call to be before the
freeing of