p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-riscv-6.17 · Seite 146

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für linux-riscv-6.17: 1109. Davon im KEV-Katalog: 0.

RSS ↗ JSON ↗
Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 8256

  1. CVE-2026-89471

    Hoch · CVSS 8.4EPSS 0,14%Keine Korrektur veröffentlicht

    power: supply: cros_usbpd-charger: bound the EC-reported port count

    In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: struct port_data *ports[EC_USB_PD_MAX_PORTS]; /* 8 entries */ ... for (i = 0; i < charger->num_charger_ports; i++) charger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that c

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  2. CVE-2026-89470

    Hoch · CVSS 8.4EPSS 0,14%Keine Korrektur veröffentlicht

    power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS

    In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  3. CVE-2026-89469

    Hoch · CVSS 8.4EPSS 0,14%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  4. CVE-2026-89468

    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.

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  5. CVE-2026-89467

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  6. CVE-2026-89466

    Hoch · CVSS 7.7EPSS 0,14%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  7. CVE-2026-89465

    Hoch · CVSS 8.4EPSS 0,14%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  8. CVE-2026-89464

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  9. CVE-2026-89463

    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,

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  10. CVE-2026-89462

    Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht

    power: supply: max17040: propagate register read errors

    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.

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  11. CVE-2026-89461

    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.

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  12. CVE-2026-89460

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  13. CVE-2026-89459

    Hoch · CVSS 7EPSS 0,14%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  14. CVE-2026-89458

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  15. CVE-2026-89457

    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.

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  16. CVE-2026-89456

    Hoch · CVSS 7EPSS 0,15%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  17. CVE-2026-89455

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  18. CVE-2026-89454

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  19. CVE-2026-89453

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  20. CVE-2026-89452

    Hoch · CVSS 8.4EPSS 0,19%Keine Korrektur veröffentlicht

    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

    linux-riscv-6.17Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

Prüfen Sie Ihren Server

Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.

Prüfen Sie Ihren Server →