p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-azure-nvidia-6.14 · Seite 68

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für linux-azure-nvidia-6.14: 1054. Davon im KEV-Katalog: 0.

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

Sicherheitslücken: 9278

  1. CVE-2026-97609

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

    netfilter: cttimeout: prevent UAF during module unload

    In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: prevent UAF during module unload nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get()

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  2. CVE-2026-97608

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

    netfilter: nf_log: unregister loggers before per-net teardown

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  3. CVE-2026-97607

    Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht

    vdpa: ifcvf: Put device on unsupported feature error

    In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Put device on unsupported feature error Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  4. CVE-2026-97606

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    fs: autofs: fix memory leak in autofs_fill_super()

    In the Linux kernel, the following vulnerability has been resolved: fs: autofs: fix memory leak in autofs_fill_super() In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  5. CVE-2026-97605

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    erofs: preserve LZMA decoders on resize failure

    In the Linux kernel, the following vulnerability has been resolved: erofs: preserve LZMA decoders on resize failure The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unr

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  6. CVE-2026-97604

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    fbdev: vfb: defer cleanup until the last reference

    In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  7. CVE-2026-97603

    Hoch · CVSS 7.1EPSS 0,21%Keine Korrektur veröffentlicht

    idpf: disable DIM work before freeing q_vectors

    In the Linux kernel, the following vulnerability has been resolved: idpf: disable DIM work before freeing q_vectors idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them. idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed q_vector. No configuration is needed t

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  8. CVE-2026-97602

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

    inet: frags: invalidate queues before flushing them

    In the Linux kernel, the following vulnerability has been resolved: inet: frags: invalidate queues before flushing them fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() u

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  9. CVE-2026-97601

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  10. CVE-2026-97600

    Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht

    ieee802154: cc2520: fix FIFOP work use-after-free

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: cc2520: fix FIFOP work use-after-free The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  11. CVE-2026-97599

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    ieee802154: hwsim: serialize pib updates to fix double-free

    In the Linux kernel, the following vulnerability has been resolved: ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(),

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  12. CVE-2026-97598

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    ipv4: fib: bound automatic table ID allocation

    In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TA

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  13. CVE-2026-97597

    Mittel · CVSS 6.8EPSS 0,22%Keine Korrektur veröffentlicht

    ipv6: flowlabel: cap duplicate leases per socket

    In the Linux kernel, the following vulnerability has been resolved: ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  14. CVE-2026-97596

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    ipvs: reject invalid states in connection template sync records

    In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  15. CVE-2026-97595

    Hoch · CVSS 7.5EPSS 0,29%Keine Korrektur veröffentlicht

    mac802154: fix use-after-free of sdata via queued RX frames

    In the Linux kernel, the following vulnerability has been resolved: mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  16. CVE-2026-97594

    Hoch · CVSS 7.8EPSS 0,16%Keine Korrektur veröffentlicht

    landlock: Fix use-after-free of the source's parent directory

    In the Linux kernel, the following vulnerability has been resolved: landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filenam

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  17. CVE-2026-97593

    Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht

    iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX

    In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX get_rso_from_iova() returns NULL when the region-first entry is invalid. Yet in get_rto_from_iova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iova_to_phys() is called on a unmapped IOVA. Fix this by adding the missing NULL check.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  18. CVE-2026-97592

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  19. CVE-2026-97591

    Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht

    s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix handling of EBUSY in PHMAC when req is pushed to crypto engine When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine.

    linux-azure-nvidia-6.14Betriebssysteme
    Veröffentlicht Aktualisiert
    Originalmeldung 1 ↗Originalmeldung 2 ↗Originalmeldung 3 ↗

  20. CVE-2026-97590

    Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht

    s390/crypto: Fix missing scrub of temp buffers with PAES algorithm

    In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with PAES algorithm In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field.

    linux-azure-nvidia-6.14Betriebssysteme
    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 →