p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de linux-gkeop · Página 193

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

Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 9412

  1. CVE-2026-64084

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

    hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) cap PDIO scan in get_multiple at ADM1266_PDIO_NR adm1266_gpio_get_multiple() iterates the PDIO portion of the caller-supplied mask using for_each_set_bit_from(gpio_nr, mask, ADM1266_GPIO_NR + ADM1266_PDIO_STATUS) { ... } where ADM1266_PDIO_STATUS is the PMBus command code (0xE9, i.e. 233), not the number of PDIO pins. The intended upper bound is ADM1266_GPIO_NR + ADM1266_PDIO_NR = 25. gpiolib hands in a mask sized for gc.ngpio (= 25 bits on this chip), so the iteration walks find_next_bit() up to 242, reading up to 217 extra bits (a h

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  2. CVE-2026-64083

    Media · CVSS 5.5EPSS 0,13%Corrección disponible

    hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the pin-status word as pins_status = read_buf[0] + (read_buf[1] << 8); right after i2c_smbus_read_block_data(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIO_STATUS/PDIO_STATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both read_buf slots are uninitialized stack memory; if it returns 1 byte, read_buf[1] is. The composed value then flows th

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  3. CVE-2026-64082

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

    riscv: Fix register corruption from uninitialized cregs on error

    In the Linux kernel, the following vulnerability has been resolved: riscv: Fix register corruption from uninitialized cregs on error compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's pt_regs, corrupting its register state and potentially leaking kernel stack contents. compat_restore_sigcontext() has the same issue: it calls cregs_to_regs() even when __copy_from_user() fails, leading to the same corruption of the signal-returning task's register state on error

    Publicación Actualización
  4. CVE-2026-64079

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

    netfilter: x_tables: allocate hook ops while under mutex

    In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: allocate hook ops while under mutex arp/ip(6)t_register_table() add the table to the per-netns list via xt_register_table() before allocating the per-netns hook ops copy via kmemdup_array(). This leaves a window where the table is visible in the list with ops=NULL. If the pernet exit happens runs concurrently the pre_exit callback finds the table via xt_find_table() and passes the NULL ops pointer to nf_unregister_net_hooks(), causing a NULL dereference: general protection fault in nf_unregister_net_hooks+0xbc/0x150 RIP: nf_unregister_net_hooks (

    Publicación Actualización
  5. CVE-2026-64078

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

    netfilter: x_tables: add and use xtables_unregister_table_exit

    In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: add and use xtables_unregister_table_exit Previous change added xtables_unregister_table_pre_exit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table: 1. The larval table has been removed already 2. existing instantiated table is no longer on the xt pernet table list. This adds the second stage helper: unlink the table from the dying list, free the hook ops (if any) and do the audit notification. It r

    Publicación Actualización
  6. CVE-2026-64077

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

    netfilter: ebtables: move to two-stage removal scheme

    In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: move to two-stage removal scheme Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible. table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.

    Publicación Actualización
  7. CVE-2026-64076

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

    netfilter: bridge: eb_tables: close module init race

    In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: eb_tables: close module init race sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nf_register_sockopt() completes, the sockopts are exposed globally. sockopt has to be registered last, just like in ip/ip6/arptables.

    Publicación Actualización
  8. CVE-2026-64073

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

    irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT

    In the Linux kernel, the following vulnerability has been resolved: irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0. After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up(). An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free. Fix this by wrapping run_irq_workd() in guard(rcu)() s

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  9. CVE-2026-64070

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

    powerpc/hv-gpci: fix preempt count leak in sysfs show paths

    In the Linux kernel, the following vulnerability has been resolved: powerpc/hv-gpci: fix preempt count leak in sysfs show paths Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb) (which calls preempt_disable()) but only call the matching put_cpu_var() on the error path under the 'out:' label. Every successful read leaks one preempt_disable(): processor_bus_topology_show() processor_config_show() affinity_domain_via_virtual_processor_show() affinity_domain_via_domain_show() (affinity_domain_via_partition_show() was already correct.) On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and eventually

    Publicación Actualización
  10. CVE-2026-64064

    Media · CVSS 5.5EPSS 0,12%Corrección disponible

    netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone

    In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_invalidate_folio() to clear dirty bit if all changes gone If a streaming write is made, this will leave the relevant modified folio in a not-uptodate, but dirty state with a netfs_folio struct hung off of folio->private indicating the dirty range. Subsequently truncating the file such that the dirty data in the folio is removed, but the first part of the folio theoretically remains will cause the netfs_folio struct to be discarded... but will leave the dirty flag set. If the folio is then read via mmap(), netfs_read_folio() will see that the page is dirty

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  11. CVE-2026-64060

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

    netfs: Fix leak of request in netfs_write_begin() error handling

    In the Linux kernel, the following vulnerability has been resolved: netfs: Fix leak of request in netfs_write_begin() error handling Fix netfs_write_begin() to not leak our ref on the request in the event that we get an error from netfs_wait_for_read().

    Publicación Actualización
  12. CVE-2026-64056

    Crítica · CVSS 9.8EPSS 0,55%Corrección disponible

    net: ethernet: cortina: Make RX SKB per-port

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sash

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  13. CVE-2026-64055

    Crítica · CVSS 9.8EPSS 0,51%Corrección disponible

    net: ethernet: cortina: Carry over frag counter

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Carry over frag counter The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if st

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  14. CVE-2026-64052

    Alta · CVSS 8.4EPSS 0,12%Sin corrección publicada

    block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()

    In the Linux kernel, the following vulnerability has been resolved: block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user() pin_user_pages_fast() can partially succeed and return the number of pages that were actually pinned. However, the bio_integrity_map_user() does not handle this partial pinning. This leads to a general protection fault since bvec_from_pages() dereferences an unpinned page address, which is 0. To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT. Kernel Oops: Oops: general protection fault, probably for non-canonical addres

    Publicación Actualización
  15. CVE-2026-64051

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

    accel/qaic: Add overflow check to remap_pfn_range during mmap

    In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Add overflow check to remap_pfn_range during mmap The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to (re)mapping beyond the VMA if the BO is too large. This can cause use after free issues when munmap() unmaps only the VMA region and not the additional mappings. To prevent this, check the remaining size of the VMA before remapping and truncate the remapped length if sg->length is too large. [jhugo: fix braces from checkpatch --strict]

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  16. CVE-2026-64048

    Alta · CVSS 7.5EPSS 0,5%Corrección disponible

    net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot

    In the Linux kernel, the following vulnerability has been resolved: net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->i

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  17. CVE-2026-64047

    Crítica · CVSS 9.8EPSS 0,51%Corrección disponible

    net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring

    In the Linux kernel, the following vulnerability has been resolved: net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message.

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  18. CVE-2026-64046

    Crítica · CVSS 9.8EPSS 0,51%Corrección disponible

    net: tls: prevent chain-after-chain in plain text SG

    In the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link: This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links. meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap: end start

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  19. CVE-2026-64039

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

    drm/msm/snapshot: fix dumping of the unaligned regions

    In the Linux kernel, the following vulnerability has been resolved: drm/msm/snapshot: fix dumping of the unaligned regions The snapshotting code internally aligns data segment to 16 bytes. This works fine for DPU code (where most of the regions are aligned), but fails for snapshotting of the DSI data (because DSI data region is shifted by 4 bytes). Fix the code by removing length alignment and by accurately printing last registers in the region. While reworking the code also fix the 16x memory overallocation in msm_disp_state_dump_regs(). Patchwork: https://patchwork.freedesktop.org/patch/725449/

    • Actualiza a 6.8.0-1049.53
    Publicación Actualización
  20. CVE-2026-64038

    Media · CVSS 4.7EPSS 0,09%Sin corrección publicada

    hwmon: (lm90) Stop work before releasing hwmon device

    In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Stop work before releasing hwmon device Sashiko reports: In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called. Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first. If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereferen

    Publicación Actualización

Comprueba tu servidor

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

Comprueba tu servidor →