power: supply: lp8727: fix use-after-free in lp8727_release_irq()
In the Linux kernel, the following vulnerability has been resolved:
power: supply: lp8727: fix use-after-free in lp8727_release_irq()
lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms
pchg->work via schedule_delayed_work(). lp8727_release_irq() currently
cancels the work before freeing the IRQ, so an IRQ delivered in between
can re-arm the work through the threaded handler. After .remove returns
the devm layer frees pchg while lp8727_delayed_func() may still run and
dereference it.
Free the IRQ first so the threaded handler is quiesced and can no longer
queue work, then cancel the delayed work to drain the final g
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
power: supply: lp8788-charger: fix use-after-free on remove
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.
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
power: supply: qcom_battmgr: fix use-after-free
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 clie
power: supply: qcom_battmgr: terminate the strings from firmware
In the Linux kernel, the following vulnerability has been resolved:
power: supply: qcom_battmgr: terminate the strings from firmware
The qcom_battmgr_sc8280xp_strcpy() takes a Pascal-style string when the
firmware sends one. Otherwise it copies all BATTMGR_STRING_LEN bytes and
leaves the destination without a terminator.
Those destinations are model_number, serial_number and oem_info, each
BATTMGR_STRING_LEN and declared next to each other. They go out to user
space as val->strval, which power_supply_format_property() prints with
"%s", so a firmware string that fills the whole field makes that read run
into the following members.
Use strs
power: supply: rt9455: quiesce delayed work before teardown
In the Linux kernel, the following vulnerability has been resolved:
power: supply: rt9455: quiesce delayed work before teardown
The threaded IRQ handler can queue pwr_rdy_work,
max_charging_time_work and batt_presence_work. pwr_rdy_work and
batt_presence_work can also queue max_charging_time_work, while
batt_presence_work can requeue itself.
rt9455_remove() cancels max_charging_time_work before
batt_presence_work. The latter can therefore queue
max_charging_time_work after it has already been cancelled:
rt9455_remove() workqueue
cancel pwr_rdy_work
cancel max_charging_time_work
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
power: supply: twl4030_charger: cancel workers via devm
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
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
power: supply: ucs1002: fix use-after-free on remove
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,
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.
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
power: supply: max17040: synchronize work cancellation on suspend
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.
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
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
s390/percpu: Fix MVIY_PERCPU() with older binutils
In the Linux kernel, the following vulnerability has been resolved:
s390/percpu: Fix MVIY_PERCPU() with older binutils
Commit a737737cdb9c ("s390/percpu: Infrastructure for more efficient
this_cpu operations") introduced MVIY_PERCPU(), which stringifies
arguments that are already C string literals. This generates an
assembler macro invocation with whitespace-separated quoted arguments:
GEN_MVIY "459712" "%r3"
GNU as versions prior to binutils 2.39 drop the separating whitespace
between quoted macro arguments during input scrubbing. They
consequently parse the invocation as a single argument and emit
repeated warnings:
Warning: missin
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
s390/dasd: Do not complete a failed ESE read as successful
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 val
Nicht bewertetEPSS 0,18%Keine Korrektur veröffentlicht
s390/dasd: Guard sysfs discipline callbacks against unallocated private data
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.
s390/dasd: Propagate partial completion length across ERP recovery
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Propagate partial completion length across ERP recovery
dasd_default_erp_postaction() copies the timing and device state from
the finished ERP request back to the original request but drops
proc_bytes. A request that was partially completed, an ESE read of a
not-yet-allocated track returns fewer bytes than requested, and then
recovered through the ERP chain loses its partial-completion length.
__dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole
request instead of requeueing the remainder, silently returning zeroed
data for the part that was nev
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
PCI: plda: Fix use-after-free of event IRQs during teardown
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
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts()
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 rem
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
iommu/amd: Put PCI device after handling PPR faults
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 late
iommu/msm: Unwind probe state on registration failure
In the Linux kernel, the following vulnerability has been resolved:
iommu/msm: Unwind probe state on registration failure
msm_iommu_probe() adds its devm-managed IOMMU object to
qcom_iommu_devices before adding the IOMMU sysfs device and registering
it with the IOMMU core.
If iommu_device_sysfs_add() fails, probe returns with the object still on
qcom_iommu_devices. The driver core then releases the devm allocation,
leaving a dangling list entry that later list walks may dereference.
If iommu_device_register() fails, the same dangling list entry remains
and the sysfs device is left registered as well.
Unwind the sysfs device and global li
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
iommu/sva: Set handle->dev before the SVA handle is visible
In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Set handle->dev before the SVA handle is visible
iommu_attach_device_pasid() installs the new SVA attach handle in the
group PASID lookup before iommu_sva_bind_device() returns. A concurrent
bind can therefore find and reuse the same handle after iommu_sva_lock is
dropped.
handle->dev was initialized after dropping iommu_sva_lock. This leaves a
window where a racing bind can return a handle whose dev pointer is still
NULL. A subsequent iommu_sva_unbind_device() can then dereference it via
handle->dev->iommu_group.
Initialize handle->dev before releasing iommu_s
iommu/tegra241-cmdqv: Reject a vSID wider than the SID_MATCH field
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Reject a vSID wider than the SID_MATCH field
tegra241_vintf_init_vsid() programs the guest-provided vSID into SID_MATCH,
whose VIRT_SID field spans bits [20:1] with bit 0 as the match-enable flag.
The HW therefore matches only a 20-bit Stream ID.
The bound check rejects only virt_sid > UINT_MAX, which admits a value far
wider than the field. The write "virt_sid << 1 | 0x1" then drops every bit
above 20: a virt_sid of 0x80000000 lands as SID_MATCH = 0x1, a valid match
on vSID 0, so the entry aliases the wrong Stream ID. Because vdev->virt_id
is guest-c