p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de linux-gcp-7.0 · Página 196

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

RSS ↗ JSON ↗
Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 6100

  1. CVE-2026-72298

    Alta · CVSS 8.4EPSS 0,18%Corrección disponible

    net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()

    In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any siz

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  2. CVE-2026-72297

    Alta · CVSS 7.1EPSS 0,16%Corrección disponible

    net: atm: reject out-of-range traffic classes in QoS validation

    In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is acc

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  3. CVE-2026-72296

    Crítica · CVSS 9.1EPSS 0,73%Corrección disponible

    net: ife: require ETH_HLEN to be pullable in ife_decode()

    In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  4. CVE-2026-72293

    Sin evaluarEPSS 0,2%Corrección disponible

    KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()

    In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault() Add missing radix_tree_preload() in _gaccess_shadow_fault() to guarantee forward progress. The core of _gaccess_shadow_fault() has been split into ___gaccess_shadow_fault() in order to simplify locking.

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  5. CVE-2026-72292

    Sin evaluarEPSS 0,2%Corrección disponible

    KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory

    In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Initialize KVM_S390_GET_CMMA_BITS memory kvm_s390_get_cmma_bits() allocates its output buffer with vmalloc(), which does not zero the returned pages: values = vmalloc(args->count); In the non-peek (migration) path, dat_get_cmma() reports a byte count spanning from the first to the last dirty page, but __dat_get_cmma_pte() writes values[gfn - start] only for pages whose CMMA dirty bit is set. The walk uses DAT_WALK_IGN_HOLES, so clean and unmapped pages that lie between two dirty pages within the reported span are visited but never store their byte. Those gaps

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  6. CVE-2026-72290

    Media · CVSS 4.8EPSS 0,21%Corrección disponible

    KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

    In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix GISC refcount leak on AIF enable failure kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path.

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  7. CVE-2026-72289

    Crítica · CVSS 9.3EPSS 0,18%Corrección disponible

    KVM: arm64: vgic: Check the interrupt is still ours before migrating it

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  8. CVE-2026-72288

    Crítica · CVSS 9.3EPSS 0,18%Corrección disponible

    KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  9. CVE-2026-72287

    Alta · CVSS 7.8EPSS 0,14%Corrección disponible

    KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks

    In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was sh

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  10. CVE-2026-72286

    Alta · CVSS 8.8EPSS 0,18%Corrección disponible

    KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs

    In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs The intra-host migration/mirroring feature is not fully implemented for SEV-SNP VMs. The proper migration requires additional SNP-specific state such as guest_req_mutex, guest_req_buf, and guest_resp_buf to be transferred or initialized on the destination. The SNP VM mirroring requires vmsa features to be copied as well otherwise ASID would be bound to SNP range while VM is detected as a SEV VM. Reject SNP source VMs in migration/mirroring until proper SNP state transfer is implemented. [sean: let lines po

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  11. CVE-2026-72285

    Alta · CVSS 7.8EPSS 0,17%Corrección disponible

    KVM: TDX: Reject concurrent change to CPUID entry count

    In the Linux kernel, the following vulnerability has been resolved: KVM: TDX: Reject concurrent change to CPUID entry count Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied ent

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  12. CVE-2026-72284

    Alta · CVSS 7.1EPSS 0,19%Corrección disponible

    KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs

    In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs Ignore KVM's internal "service pending PV EOI" request if the vCPU has disabled PV EOIs since the request was made. Asserting that PV EOIs are enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e. if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables PV EOIs. kernel BUG at arch/x86/kvm/lapic.c:3338! Oops: invalid opcode: 0000 [#1] SMP CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT Hardware name: QEMU Standard P

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  13. CVE-2026-72283

    Alta · CVSS 8.8EPSS 0,18%Corrección disponible

    KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails

    In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails Nullify irqfd->producer if updating the IRTE for bypass fails, as leaving a dangling pointer will result in a use-after-free if the irqfd is reachable through KVM's routing, but the producer is freed separately. E.g. for VFIO PCI, the producer is embedded in struct "vfio_pci_irq_ctx" and freed when the vector is disabled, which can happen independent of routing updates. [sean: drop PPC change, massage changelog]

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  14. CVE-2026-72282

    Alta · CVSS 7.8EPSS 0,18%Corrección disponible

    KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers

    In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  15. CVE-2026-72280

    Alta · CVSS 7.1EPSS 0,19%Corrección disponible

    KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2 It is entirely possible for a guest to write to the ZCR_EL2 sysreg alias while in a nested context, as it is expected if FEAT_NV2 is advertised to the L1 hypervisor. Get rid of the bogus WARN which, since the hyp vectors were installed at this point, has the effect of a hyp_panic...

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  16. CVE-2026-72279

    Crítica · CVSS 9EPSS 0,19%Corrección disponible

    KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR KVM currently maps the L1 VNCR into the host stage-1 by relying entirely on the permissions of the guest stage-1. At the same time, it is entirely possible that the backing PFN is read-only (e.g. RO memslot), meaning that the L1 VNCR should use at most a read-only mapping. Cache the writability of the PFN in the VNCR TLB and use it to constrain the resulting fixmap permissions. Promote VNCR permission faults to an SEA in the case where the guest attempts to write to a read-only endpoint. Conveniently, this also plu

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  17. CVE-2026-72278

    Crítica · CVSS 9.3EPSS 0,19%Corrección disponible

    KVM: arm64: nv: Re-translate VNCR before injecting abort

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  18. CVE-2026-72277

    Crítica · CVSS 9.3EPSS 0,19%Corrección disponible

    KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory

    In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable memory attributes, even if the underlying PFN isn't memory. This gets particularly hairy if the endpoint doesn't support cacheable memory attributes, potentially throwing an SError on writeback... While KVM does permit cacheable memory attributes on certain PFNMAP VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the simpler thing for now and just reject everything that isn't memory.

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1013.13~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  19. CVE-2026-72276

    Sin evaluarEPSS 0,21%Corrección disponible

    fbdev: metronomefb: fix potential memory leak in metronomefb_probe()

    In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  20. CVE-2026-72275

    Sin evaluarEPSS 0,21%Corrección disponible

    fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()

    In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().

    linux-gcp-7.0Sistemas operativos
    • Actualiza a 7.0.0-1014.14~24.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

Comprueba tu servidor

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

Comprueba tu servidor →