p PatchFirst

PatchFirst · Свежие уязвимости

Уязвимости linux-oem-6.17 · Страница 126

За последние 30 дней в linux-oem-6.17 опубликовано уязвимостей: 946; в каталоге KEV: 0.

Фильтры уязвимостей
Сбросить фильтры

Уязвимостей: 7860

  1. CVE-2026-89454

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    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

    Опубликовано Обновлено
  2. CVE-2026-89453

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    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

    Опубликовано Обновлено
  3. CVE-2026-89452

    Высокий · CVSS 8.4EPSS 0,19%Нет опубликованного исправления

    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

    Опубликовано Обновлено
  4. CVE-2026-89451

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    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

    Опубликовано Обновлено
  5. CVE-2026-89450

    Высокий · CVSS 8.8EPSS 0,13%Нет опубликованного исправления

    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

    Опубликовано Обновлено
  6. CVE-2026-89449

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add

    In the Linux kernel, the following vulnerability has been resolved: iommu: Fix dev_iommu memory leak when device_add fails in iommu_mock_device_add iommu_mock_device_add() first calls iommu_fwspec_init(), which on success allocates both dev->iommu (via dev_iommu_get()) and dev->iommu->fwspec. If the subsequent device_add(dev) call fails, the error path only calls iommu_fwspec_free(dev), which frees fwspec but leaves dev->iommu still allocated. This triggers the following kmemleak report when fuzzing with Syzkaller: BUG: memory leak unreferenced object 0xffff888011e0a200 (size 192): comm "syz.1.1695", pid 24885, jiffies 4295222527 hex

    Опубликовано Обновлено
  7. CVE-2026-89448

    Критический · CVSS 9.3EPSS 0,14%Нет опубликованного исправления

    iommu/vt-d: Force requesting ACS when tboot is enabled

    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().

    Опубликовано Обновлено
  8. CVE-2026-89447

    Без оценкиEPSS 0,22%Нет опубликованного исправления

    iommufd: Avoid locking internal accesses during unmap

    In the Linux kernel, the following vulnerability has been resolved: iommufd: Avoid locking internal accesses during unmap iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke. However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj(). Check for internal accesses first so skipped entries are never locked.

    Опубликовано Обновлено
  9. CVE-2026-89446

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    iommufd: Release current IOAS on xa_store() failure

    In the Linux kernel, the following vulnerability has been resolved: iommufd: Release current IOAS on xa_store() failure iommufd_take_all_iova_rwsem() takes an object reference and the iova_rwsem write lock before storing the IOAS in the temporary ioas_list xarray. If xa_store() fails, the current IOAS has not been inserted into ioas_list yet. iommufd_release_all_iova_rwsem() only unwinds IOAS objects already present in that xarray, so it cannot release the current IOAS. Release the current IOAS rwsem and object reference before unwinding the previously stored entries.

    Опубликовано Обновлено
  10. CVE-2026-89445

    Высокий · CVSS 8.8EPSS 0,17%Нет опубликованного исправления

    iommufd: Fix UAF in selftest IOPF reporting

    In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix UAF in selftest IOPF reporting IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from group->pasid_array without synchronizing against PASID detach, then a concurrent iommu_report_device_fault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufd_attach_handle. TRIGGER_IOPF then dereferences the freed handle, causing a UAF. Fix by adding a iopf_rwsem in mock_dev to follow the expected design of a real driver. Hold its read side across the whole iommu_report_device_fault() call, and

    Опубликовано Обновлено
  11. CVE-2026-89444

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer

    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.

    Опубликовано Обновлено
  12. CVE-2026-89443

    Высокий · CVSS 7.1EPSS 0,16%Нет опубликованного исправления

    platform/x86: ISST: Validate level in perf mask ioctls

    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

    Опубликовано Обновлено
  13. CVE-2026-89442

    Высокий · CVSS 7.8EPSS 0,17%Нет опубликованного исправления

    platform/x86: ISST: Validate socket ID in clos_assoc ioctl

    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-b

    Опубликовано Обновлено
  14. CVE-2026-89441

    Высокий · CVSS 7.8EPSS 0,13%Нет опубликованного исправления

    mmc: via-sdmmc: cancel card-detect work on remove

    In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: cancel card-detect work on remove Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the i

    Опубликовано Обновлено
  15. CVE-2026-89440

    Высокий · CVSS 7.8EPSS 0,17%Нет опубликованного исправления

    mmc: via-sdmmc: stop card-detect handling on probe failure

    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

    Опубликовано Обновлено
  16. CVE-2026-89439

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    platform/x86: ISST: Add a NULL check for sst_inst[]

    In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Add a NULL check for sst_inst[] To be consistent with other places, add a NULL check for failed socket loading by checking isst_common.sst_inst[].

    Опубликовано Обновлено
  17. CVE-2026-89438

    Без оценкиEPSS 0,21%Нет опубликованного исправления

    platform/x86: ISST: Validate logical CPU id and clos id

    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.

    Опубликовано Обновлено
  18. CVE-2026-89437

    Без оценкиEPSS 0,17%Нет опубликованного исправления

    platform/x86: int1092: Fix potential memory leak in sar_probe()

    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.

    Опубликовано Обновлено
  19. CVE-2026-81018

    Без оценкиEPSS 0,16%Нет опубликованного исправления

    platform/x86: think-lmi: Free system certificate signatures

    In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Free system certificate signatures Multi-certificate support also allows the system authentication object to store ->signature and ->save_signature, which leak when the driver is removed. Free the signatures to avoid leaking memory.

    Опубликовано Обновлено
  20. CVE-2026-81017

    Высокий · CVSS 8.4EPSS 0,18%Нет опубликованного исправления

    platform/chrome: sensorhub: Bound the EC-reported sensor number

    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 f

    Опубликовано Обновлено

Проверьте свой сервер

Сопоставьте установленный стек и версии со свежими базами уязвимостей.

Проверьте свой сервер →