| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Guard legacy bundles without method_elm
The legacy write() path dispatches through a uverbs_api_write_method, but
the uverbs_attr_bundle passed to provider code does not have an ioctl
method element. If malformed provider input causes the common uverbs
validation code to emit an error message, uverbs_get_handler_fn()
dereferences the uninitialized method_elm pointer.
Initialize method_elm explicitly for legacy bundles and make
uverbs_get_handler_fn() return NULL when no ioctl method is present. The
legacy dispatcher continues to use its local write method, while the ioctl
path continues to use the registered ioctl handler. |
| In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Free cpu_buffer::free_page with subbuf_order
When sub-buffers use an order greater than 0, cpu_buffer->free_page is
allocated with subbuf_order. Use the correct order for
cpu_buffer->free_page. |
| In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix double-free of trailer_buf on readdir copy failure
On a readdir downcall, orangefs_devreq_write_iter() frees
op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails,
but does not clear the pointer before goto Efault. The waiter in
do_readdir() is then woken with a negative status and frees the same
pointer again on its r < 0 path, causing a deterministic double-free.
A client holding /dev/pvfs2-req triggers it by sending a readdir
downcall whose declared trailer_size exceeds the bytes it supplies.
Clear the pointer after freeing so the readdir-side vfree() becomes a
no-op. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: always run deallocs on copy-on-write completion
Local fuzzing of 6.12.94 has found the following memory leak
caused by doing 'copy_file_range()' within the same filesystem:
unreferenced object 0xffff88812192c980 (size 32):
comm "syz.0.49", pid 12095, jiffies 4294964143
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................
c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............
backtrace (crc 7068d63f):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline]
ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786
ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline]
ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613
ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline]
__ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985
ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237
ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825
ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138
ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098
ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline]
ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline]
ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349
ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline]
ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470
ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline]
ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451
iter_file_splice_write+0x890/0xf60 fs/splice.c:743
do_splice_from fs/splice.c:944 [inline]
direct_splice_actor+0x232/0x480 fs/splice.c:1167
splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111
do_splice_direct_actor fs/splice.c:1210 [inline]
do_splice_direct+0x10f/0x1c0 fs/splice.c:1236
do_sendfile+0x430/0xbf0 fs/read_write.c:1388
unreferenced object 0xffff88812192c5c0 (size 32):
comm "syz.0.49", pid 12095, jiffies 4294964143
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p..............
backtrace (crc afec850f):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
kzalloc_noprof include/linux/slab.h:1014 [inline]
ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793
ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline]
ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613
ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline]
__ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985
ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237
ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825
ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138
ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098
ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline]
ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline]
ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349
ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline]
ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470
ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline]
ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451
iter_file_splice_write+0x890/0xf60 fs/splice.c:743
do_splice_from fs/splice.c:9
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix readdir position truncation on 32-bit kernels
In ocfs2_dir_foreach_blk_el(), the directory cookie position is
rebuilt with
ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask
~(sb->s_blocksize - 1)
is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size). In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000. The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB.
When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.
This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
for all non-inline directories, so a directory large enough to cross
4 GiB reaches it.
This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat, and the
fix mirrors the equivalent ext4 fix in this series. Cast the operand
to loff_t so the mask is 64-bit before the AND:
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
64-bit kernels are unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
lockd: fix NULL dereference on lockowner allocation failure
nlmclnt_locks_init_private() installs NLM file lock operations even when
nlmclnt_find_lockowner() fails to allocate a lockowner. nlmclnt_proc()
then returns -ENOMEM, but the VFS still tears down the partially
initialized file_lock and calls locks_release_private().
That invokes nlmclnt_locks_release_private(), which dereferences
fl->fl_u.nfs_fl.owner and crashes because the owner was never installed.
Clear fl_ops before attempting to initialize the NLM private state, and
install the NLM lock operations only after a lockowner has been allocated
successfully. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq24257: fix use-after-free on remove
The STAT-pin interrupt is devm-managed, so it stays armed until the devm
cleanup that runs after remove() returns. remove() cancels
bq->iilimit_setup_work while the threaded handler can still fire; that
handler reschedules the work and dereferences bq, so the work runs
against freed memory once devm frees bq.
Make the delayed work device-managed with devm_delayed_work_autocancel(),
registered before the interrupt request. The devm cleanup then releases
the interrupt first, so the handler can no longer reschedule the work,
and cancels the work before bq is freed. The explicit
cancel_delayed_work_sync() in remove() is no longer needed and is dropped.
Found by static analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq25890: Fix power_supply reference leak
bq25890_fw_probe() acquires a reference to a secondary charger using
power_supply_get_by_name(), but the reference is not released on later
probe failures or on driver detach.
In particular, failures after bq25890_fw_probe() returns successfully,
such as a failure in bq25890_hw_init(), also leak the reference.
Register a device-managed cleanup action immediately after acquiring
the secondary charger. This releases the reference on all subsequent
probe failures and on driver detach.
Found by code review. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: lp8788-charger: fix use-after-free on remove
lp8788_charger_remove() flushes charger_work before unregistering the
IRQs. An IRQ thread can queue charger_work after flush_work() has
returned. The work can then run after devres frees pchg and dereference
it in lp8788_charger_event().
Unregister the IRQs first. free_irq() waits for any running threaded
handler, so no handler can queue more work afterwards. Then use
cancel_work_sync() to cancel pending work or wait for running work to
finish.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: qcom_battmgr: fix use-after-free
qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service
comes up, and the worker recovers battmgr through container_of() to issue
firmware requests. The PMIC GLINK client stays on the client list until
its devres release action runs, so a PDR notification can keep queueing
the work, and a pending or running worker can access battmgr after devres
frees it.
Make enable_work device-managed with devm_work_autocancel(), registered
before the PMIC GLINK client is allocated. The devres cleanup then
releases the client first, so no further notification can queue the work,
and cancels the work before battmgr is freed.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: twl4030_charger: cancel workers via devm
bci is devm-allocated. Two workers (bci->work and bci->current_worker)
dereference it. twl4030_bci_remove() disables charging and masks
interrupts. It cancels neither worker. A worker pending at remove() can
run after devm frees bci.
The USB transceiver comes from devm_usb_get_phy_by_node(). devm
unregisters its notifier only after remove() returns. A cancel_work_sync()
in remove() can then race a notifier reschedule. devm_work_autocancel()
and devm_delayed_work_autocancel() avoid that. They cancel the workers
during devm release, before bci is freed.
The current_worker is registered first, since devm will cancel in
reverse order and bci->work can reschedule current_worker.
[Move comment about order into the commit message] |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: ucs1002: fix use-after-free on remove
ucs1002 has no remove callback, so unbind runs entirely through devm.
The alert IRQ handler queues the health_poll delayed work, and the work
reschedules itself while the chip reports a bad-health condition. devm
frees the alert IRQ, which only synchronizes the handler; it does not
cancel the delayed work, which can then run after devm frees the driver
data and dereference it.
Register health_poll with devm_delayed_work_autocancel() before the
alert IRQ is requested. devm then frees the IRQ before cancelling the
work, so the handler can no longer queue it and the work is cancelled
before the driver data is freed.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: max17040: propagate register read errors
max17040_get_vcell() and max17040_get_soc() ignore errors returned by
regmap_read(). When an I2C transfer fails, the uninitialized register
value is converted and reported to userspace as a valid voltage or state
of charge. The polling worker can also replace the cached state of charge
with the bogus value and emit a spurious change event.
Propagate read errors through the power supply get_property callback and
keep the last valid cached state of charge when polling fails. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: max17040: synchronize work cancellation on suspend
max17040_work() requeues itself after every poll. cancel_delayed_work()
only cancels a pending instance and does not wait for a callback that is
already running.
If system suspend races with the polling callback, the callback can
continue accessing the fuel gauge and requeue itself after the suspend
callback returns.
Use cancel_delayed_work_sync() to ensure polling is quiesced before
suspend completes. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
The command 'perf stat -e cycles -- <command>' crashes the kernel
when CPUs are hotplug added during that run.
Root cause is the allocation of struct cpu_cf_events at first
event initialization. The allocation is dynamic and the first
event that has task context creates such a structure for
each online CPU. This is not sufficient. CPUs may be offline
during event creation and can be set online during the
perf run time. For example commands
# echo 0 > /sys/devices/system/cpu/cpu1/online
# perf stat -e cycles -i -- stress-ng -t10s --matrix X
# sleep 1
# echo 1 > /sys/devices/system/cpu/cpu1/online
create an event for CPUs 0,2-X. Since the events are created with
task-context, the scheduler will eventually schedule the program
on CPU1. This CPU has not created and initialized any per
CPU event infrastructure as that CPU was not online at the time
of the perf invocation. Thus when the scheduler runs stress-ng
on CPU1, the function cpumf_pmu_add() refers to a NULL pointer:
struct cpu_cf_events *cpuhw = this_cpu_cfhw();
This function call is invoked after the task stress-ng has been
made runnable on CPU1. And this_cpu_cfhw() returns NULL.
The result is a panic:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000000000000 TEID: 0000000000000483
....
Krnl PSW : 0404d00180000000 000003ef8291fd0c (cpumf_pmu_add+0x3c/0x80)
....
Call Trace:
[<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80
[<000003ef82bb5e3e>] event_sched_in+0xae/0x190
[<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390
[<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0
[<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50
[<000003ef82bb6a30>] ctx_sched_in+0x180/0x260
[<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0
[<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0
[<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250
....
Last Breaking-Event-Address:
[<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40
The issue arises only in per-task context when the CPUMF facility is
used and the scheduler picks a random CPU for such a process to run on.
The scheduler enables the CPUMF infrastructure via PMU callback
functions pmu::add() and pmu::del().
Introduce a CPU hotplug prepare/dead callback pair which creates and
removes the per CPU counter data while the CPU is offline. Count the
users which track every CPU (cpu == -1), that is perf_event_open()
events with task context and /dev/hwctr device sessions, in the new
counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex.
This ensures the infrastructure is available when
new CPU is selected to run the per-task context process.
In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference
pointer to data structures is set to NULL before the data is freed
to prevent interrupt handlers to access stale data.
[gor@linux.ibm.com: change commit message] |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Do not complete a failed ESE read as successful
dasd_int_handler() completes an NRF read of an unallocated ESE track by
calling ese_read() and unconditionally marking the request
DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has
zeroed the destination buffer: a failed sense-data parse or a current
track outside the requested range both return early, leaving the
destination pages untouched. The request is still completed successfully,
so the block layer is handed stale / uninitialized memory instead of
zeros.
Check the ese_read() return value and fail the request through the normal
error path instead of forcing DASD_CQR_SUCCESS. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Guard sysfs discipline callbacks against unallocated private data
Several sysfs show/store handlers call a discipline callback that
dereferences device->private, either directly or through the
DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline
is assigned before check_device() allocates device->private, so an
unprivileged read of one of these world-readable attributes in that window
dereferences a NULL pointer and panics.
Guard the dereference inside each callback that actually touches
device->private. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: plda: Fix use-after-free of event IRQs during teardown
plda_pcie_irq_domain_deinit() removes pcie->event_domain via
irq_domain_remove(), but the per-event IRQs mapped from that domain
are requested with devm_request_irq() in plda_init_interrupts(). The
actual free_irq() for a devm-managed IRQ is deferred by devres until
after the calling probe()/remove() function returns.
This means irq_domain_remove() can free the domain's internal data
before the deferred free_irq() for IRQs still mapped into it has run.
When devres later processes that deferred cleanup, it can end up
dereferencing the already-freed domain.
Free each event IRQ explicitly with devm_free_irq() before removing
the domain. This triggers the free immediately and removes the IRQ
from the devres tracking list, so devres will not attempt to free it
a second time later.
Also dispose of the event, INTx, and MSI IRQ mappings with
irq_dispose_mapping() before their owning domains are removed.
Finally, guard the calls to irq_set_chained_handler_and_data() for
pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when
those fields hold a valid (>0) IRQ number.
This is a pre-existing issue, flagged by automated review during work
on an earlier, unrelated patch to this driver.
Build-tested and boot-tested on StarFive VisionFive v1.2A board |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts()
plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but
does not unwind them when later step fails.
If platform_get_irq() or either irq_create_mapping() fails
in plda_init_interrupts(), the domains are never deinitialized. If
irq_create_mapping() fails, port->intx_irq stays initialized.
Hence, remove the IRQ domains in the error path by calling
plda_pcie_irq_domain_deinit().
Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and
msi_irq mappings itself before removing their domains, the msi_irq
mapping failure path can go directly to err_irq_domain_deinit instead of
disposing of port->intx_irq separately first.
This issue was found by automated review of sashiko-bot
[mani: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Put PCI device after handling PPR faults
iommu_call_iopf_notifier() looks up the requester with
pci_get_domain_bus_and_slot(), which returns a PCI device with its
reference count incremented.
Neither the successful iommu_report_device_fault() path nor the abort
path drops that reference, so every handled PPR request leaks a PCI
device reference.
This is the same ownership rule that was fixed for the old iommu_v2
ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device
refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was
added later as a separate PPR/IOPF notifier path.
Drop the PCI device reference after handling the PPR entry. |
