p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de linux-kvm · Página 185

Vulnerabilidades publicadas para linux-kvm en los últimos 30 días: 323. Incluidas en el catálogo KEV: 0.

Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 5670

  1. CVE-2025-38090

    Alta · CVSS 7.8EPSS 0,2%Sin corrección publicada

    drivers/rapidio/rio_cm.c: prevent possible heap overwrite

    In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.

    Publicación Actualización
  2. CVE-2025-38086

    Media · CVSS 5.5EPSS 0,21%Sin corrección publicada

    net: ch9200: fix uninitialised access during mii_nway_restart

    In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():

    Publicación Actualización
  3. CVE-2025-38085

    Alta · CVSS 7.8EPSS 0,16%Sin corrección publicada

    mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

    In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI throug

    Publicación Actualización
  4. CVE-2025-38084

    Alta · CVSS 7.8EPSS 0,21%Sin corrección publicada

    mm/hugetlb: unshare page tables during VMA split, not before

    In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the r

    Publicación Actualización
  5. CVE-2024-36347

    Media · CVSS 6.4EPSS 0,11%Sin corrección publicada

    CVE-2024-36347

    Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious microcode, potentially resulting in loss of integrity of x86 instruction execution, loss of confidentiality and integrity of data in x86 CPU privileged context and compromise of SMM execution environment.

    Publicación Actualización
  6. CVE-2022-50224

    Media · CVSS 5.5EPSS 0,2%Sin corrección publicada

    KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT

    In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set. KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM: Refuse to load kvm_amd if NX support is not available") for exactly this reason, but apparently it never occurred to anyone to actually test NPT with the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bit

    Publicación Actualización
  7. CVE-2022-50213

    Alta · CVSS 7.8EPSS 0,24%Sin corrección publicada

    netfilter: nf_tables: do not allow SET_ID to refer to another table

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow SET_ID to refer to another table When doing lookups for sets on the same batch by using its ID, a set from a different table can be used. Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free. When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table. This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.

    Publicación Actualización
  8. CVE-2022-50181

    Media · CVSS 5.7EPSS 0,25%Sin corrección publicada

    virtio-gpu: fix a missing check to avoid NULL dereference

    In the Linux kernel, the following vulnerability has been resolved: virtio-gpu: fix a missing check to avoid NULL dereference 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. [ kraxel: minor codestyle fixup ]

    Publicación Actualización
  9. CVE-2022-50175

    Media · CVSS 5.5EPSS 0,24%Sin corrección publicada

    media: tw686x: Fix memory leak in tw686x_video_init

    In the Linux kernel, the following vulnerability has been resolved: media: tw686x: Fix memory leak in tw686x_video_init video_device_alloc() allocates memory for vdev, when video_register_device() fails, it doesn't release the memory and leads to memory leak, call video_device_release() to fix this.

    Publicación Actualización
  10. CVE-2022-50174

    Media · CVSS 5.7EPSS 0,19%Sin corrección publicada

    net: hinic: avoid kernel hung in hinic_get_stats64()

    In the Linux kernel, the following vulnerability has been resolved: net: hinic: avoid kernel hung in hinic_get_stats64() When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung. The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x23

    Publicación Actualización
  11. CVE-2022-50166

    Media · CVSS 5.5EPSS 0,18%Sin corrección publicada

    Bluetooth: When HCI work queue is drained, only queue chained work

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: When HCI work queue is drained, only queue chained work The HCI command, event, and data packet processing workqueue is drained to avoid deadlock in commit 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state"). There is another delayed work, which will queue command to this drained workqueue. Which results in the following error report: Bluetooth: hci2: command 0x040f tx timeout WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140 Workqueue: events hci_cmd_timeout RIP: 0010:__queue_work+0xdad/0x1140 RSP: 0000:ffffc

    Publicación Actualización
  12. CVE-2022-50163

    Alta · CVSS 7.8EPSS 0,26%Sin corrección publicada

    ax25: fix incorrect dev_tracker usage

    In the Linux kernel, the following vulnerability has been resolved: ax25: fix incorrect dev_tracker usage While investigating a separate rose issue [1], and enabling CONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2] An ax25_dev can be used by one (or many) struct ax25_cb. We thus need different dev_tracker, one per struct ax25_cb. After this patch is applied, we are able to focus on rose. [1] https://lore.kernel.org/netdev/[email protected]/ [2] [ 205.798723] reference already released. [ 205.798732] allocated in: [ 205.798734] ax25_bind+0x1a2/0x230 [ax25] [ 205.798747] __sys

    Publicación Actualización
  13. CVE-2022-50159

    Media · CVSS 5.5EPSS 0,19%Sin corrección publicada

    of: check previous kernel's ima-kexec-buffer against memory bounds

    In the Linux kernel, the following vulnerability has been resolved: of: check previous kernel's ima-kexec-buffer against memory bounds Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append='mem=16G' <snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc0000000008

    Publicación Actualización
  14. CVE-2022-50138

    Media · CVSS 5.5EPSS 0,25%Sin corrección publicada

    RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()

    In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak.

    Publicación Actualización

Comprueba tu servidor

Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.

Comprueba tu servidor →