| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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: 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:
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 never read.
Carry proc_bytes over to the original request like the other
per-request state. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Force requesting ACS when tboot is enabled
Currently the conditions of requesting ACS in detect_intel_iommu()
don't include tboot, leading to a possible misconfiguration with ACS
disabled (e.g. due to user opts) while iommu is later forced on by
tboot_force_iommu().
Fix it by checking tboot in detect_intel_iommu(). |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer
set_attribute() populates the security area of the BIOS attribute request
buffer with the current admin password via populate_security_buffer(), then
dumps the whole request buffer with print_hex_dump_bytes(). This can expose
the plaintext admin password in the kernel log.
The same issue was fixed for the password attribute path by
commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump
plaintext password data"). Remove the remaining dump from the BIOS
attribute path. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate level in perf mask ioctls
isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask() use the
user-provided level as an index into perf_levels[] via
_read_pp_level_info() and _read_bf_level_info(), but neither helper
validates it first.
The adjacent level-info helpers reject levels above max_level before
reading the same per-level register block. Add the same bounds checks to
the mask helpers, and reject disabled SST-PP levels in
isst_if_get_perf_level_mask() to match isst_if_get_perf_level_info().
This prevents out-of-bounds reads from the per-level offset table on
invalid ioctl input. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate socket ID in clos_assoc ioctl
isst_if_clos_assoc() validates the user-supplied socket_id with
'socket_id > topology_max_packages()', but isst_common.sst_inst[] is
allocated with topology_max_packages() entries, so the valid index range
is [0, topology_max_packages()). The '>' comparison lets
socket_id == topology_max_packages() pass and index one entry past the
array.
In addition, isst_common.sst_inst[socket_id] is NULL for an in-range
package that has no bound TPMI SST instance, and the pointer is used
without a NULL check. Both the out-of-bounds entry and the NULL pointer
are then dereferenced by map_partition_power_domain_id() and the
following power_domain_info access.
Reject socket_id >= topology_max_packages() and a NULL sst_inst, matching
the checks already performed by get_instance(). |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: via-sdmmc: stop card-detect handling on probe failure
request_irq() registers the SD card-detect interrupt and the probe enables
it before mmc_add_host() runs. If mmc_add_host() fails, the error path only
unmaps the registers and returns: the interrupt stays registered, so the
handler keeps running against the host once it is freed. via_sdc_isr()
dereferences sdhost and its MMIO base and schedules carddet_work, which
via_sdc_card_detect() also runs against freed memory through its
container_of() dereference.
Add a probe-error path that disables and frees the interrupt and cancels
carddet_work before unmapping. carddet_work can re-enable the device
interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it
again after cancelling the work.
This issue was found by an in-house static analysis tool and confirmed by
manual code review. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Validate logical CPU id and clos id
Validate max CLOS ID and logical CPU ID for core power feature.
Reject any clos level or logical CPU number greater than the
supported maximum. These are used to calculate MMIO offset. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int1092: Fix potential memory leak in sar_probe()
The memory allocated for device_mode_info in parse_package() called by
sar_get_data() is not freed in some of the error paths in sar_probe().
Fix that by converting to use device managed allocations. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: sensorhub: Bound the EC-reported sensor number
Each EC FIFO event carries an 8-bit sensor number (in->sensor_num).
cros_ec_sensorhub_ring_handler() validates the FIFO event count, the
per-read count and the ring bound, but not the sensor number, which
cros_ec_sensor_ring_process_event() then uses unchecked to index
sensorhub->batch_state[] - allocated with only sensorhub->sensor_num
entries. A sensor number of sensor_num or larger is an out-of-bounds
read and write of batch_state[].
Validate the sensor number in the ring handler, where each event is read
from the EC, and drop a malformed event before it is used. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store()
sk_store() and kek_store() strip a trailing newline from the sysfs
write before allocating the key buffer:
length = count;
if (buf[length - 1] == '\n')
length--;
bioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL);
but then pass the original "count" (not "length") as the copy size to
hp_wmi_perform_query(), which memcpy()s that many bytes out of the
"length"-sized allocation, reading one byte past it whenever the write
ends in a newline, the normal case for a shell "echo" into sysfs.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg]
Read of size 28 at addr ffff88813c8e2b80 by task python3/16022
...
sk_store+0xa7/0x240 [hp_bioscfg]
kernfs_fop_write_iter+0x3e1/0x5d0
...
The buggy address is located 0 bytes inside of
allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b)
Reproduced identically for kek_store, and at multiple write sizes
(28, 57, 201 bytes), each time reading exactly one byte past a
kmemdup() allocation one byte smaller than the write.
Fix by passing "length" instead of "count" to hp_wmi_perform_query()
in both functions. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix heap OOB read on empty password write
validate_password_input() computes length = strlen(buf) and then
checks buf[length - 1] to strip a trailing newline, without checking
that length is nonzero first. Writing an empty string (a bare '\n')
to current_password or new_password gives length == 0, and
buf[length - 1] reads buf[-1], one byte before the heap allocation
holding the copied input.
KASAN confirms this directly:
BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
Read of size 1 at addr ffff88811bd8da9f by task sh/13740
...
store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg]
current_password_store+0x14/0x20 [hp_bioscfg]
...
The buggy address is located 23 bytes to the right of
allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88)
Reproduced identically via new_password_store. Execution continues
past the bad read (the garbage byte only affects whether "length" is
decremented by one), so the write completes and returns success; this
is a pure information read past the buffer, not a crash, but it is
still an out-of-bounds access KASAN correctly flags.
Fix by only checking buf[length - 1] when length is nonzero. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer()
hp_get_string_from_buffer() clamps the converted string length against
the destination buffer size with "size > dst_size", so when the
converted length is exactly equal to dst_size, conv_dst_size is left
at dst_size and the unconditional NUL terminator write
dst[conv_dst_size] = 0;
lands one byte past the destination buffer. This is the same shape of
bug as the previously fixed off-by-one in hp_convert_hexstr_to_str():
the buffer is sized correctly for the content, but the terminator
write is never checked against that size.
Fix by changing the comparison to ">=" so conv_dst_size is always left
with room for the terminator.
All fixed-size destinations that reach this function (path[512],
current_value[512], current_password/current_value[64], and the
per-entry buffers in encodings[][512] and prerequisites[][512]) are
affected. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: hp-bioscfg: pass validated element count to package parsers
The per-type package parsers are handed the wrong element count.
hp_init_bios_package_attribute() validates obj->package.count and then
calls one of the five hp_populate_*_package_data() wrappers (string,
integer, enumeration, ordered list, password). Each wrapper forwards a
count to its hp_populate_*_elements_from_package() parser, but instead
of forwarding the validated obj->package.count it derives the count
from elements[0]. elements[0] is the NAME field and is always an
ACPI_TYPE_STRING, so reading ->package.count from it in fact reads
->string.length through the union acpi_object. The parsers thus bound
themselves against the length of the name string rather than against
the real number of elements in the package.
This is safe today because hp_init_bios_package_attribute() refuses any
package that has fewer than the type's element count, so a parser only
ever runs on a full package and never reads past it regardless of the
bogus bound.
An upcoming change relaxes that check to accept shorter packages. Once
a parser can receive fewer elements than its per-type count, a bound
taken from the name length no longer reflects the array size, and the
"elem < count" loop conditions and "elem + n >= count" sub-loop guards
read past the end of elements[] - an out-of-bounds heap read.
Forward the validated obj->package.count to every *_package_data()
wrapper so the parsers bound themselves against the real package size.
This does not change behaviour for the packages that enumerate
correctly today and is a prerequisite for accepting shorter packages
safely. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: honor task_work cancellation
io_waitid_cb() may run through the fallback task_work path when
task_work_add() can no longer queue work to the originating task. The
fallback runs from a kworker and io_uring marks such task work as
canceled through tw.cancel.
io_waitid_cb() currently ignores tw.cancel and calls __do_wait().
waitid is task-context dependent: __do_wait() performs child lookup
relative to current, and the retry path also uses
current->signal->wait_chldexit. If the callback runs from the fallback
kworker, current is therefore not the task that submitted the request.
Honor tw.cancel before entering __do_wait(). Complete the request with
-ECANCELED and skip the siginfo copy, since canceled task work may run
without the submitting task's userspace execution context.
Keep the existing siginfo handling for normal waitid completion and
explicit cancellation. |
