p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-gcp-fips · Seite 138

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für linux-gcp-fips: 810. Davon im KEV-Katalog: 0.

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 7660

  1. CVE-2026-74394

    Kritisch · CVSS 9.8EPSS 0,54%Korrektur verfügbar

    RDMA/srpt: fix integer overflow in immediate data length check

    In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  2. CVE-2026-74391

    Nicht bewertetEPSS 0,17%Korrektur verfügbar

    tracing: Bound synthetic-field strings with seq_buf

    In the Linux kernel, the following vulnerability has been resolved: tracing: Bound synthetic-field strings with seq_buf The synthetic field helpers build a prefixed synthetic variable name and a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The current code appends those strings with raw strcat(), so long key lists, field names, or saved filters can run past the end of the staging buffers. Build both strings with seq_buf and propagate -E2BIG if either the synthetic variable name or the generated command exceeds MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while using the helper intended for bounded command c

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  3. CVE-2026-74390

    Hoch · CVSS 7.8EPSS 0,13%Korrektur verfügbar

    RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs

    In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyo

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  4. CVE-2026-74389

    Nicht bewertetEPSS 0,17%Korrektur verfügbar

    RDMA/hns: Fix log flood after cmd_mbox failure

    In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix log flood after cmd_mbox failure hns_roce_cmd_mbox() is the command interface between driver and hardware. When hardware is abnormal, the unlimited error printings after hns_roce_cmd_mbox() failure will cause log flood and even system crash. Replace ibdev_err() and ibdev_warn() with their ratelimited versions in the error handling path after hns_roce_cmd_mbox() (and its wrappers hns_roce_create_hw_ctx/hns_roce_destroy_hw_ctx) fails.

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  5. CVE-2026-74388

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

    ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data

    In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data The OSS sequencer processes the input MIDI bytes into a sequencer event to be dispatched later (in snd_seq_oss_midi_putc() called from snd_seq_oss_process_event()). When it's a SysEx data, the event record contains data.ext.ptr pointer to the original SysEx bytes, and the referred data is copied into the pool afterwards at dispatching. The problem is that, if the sequencer port gets closed concurrently before the dispatch, the OSS sequencer core also releases the resources (in snd_seq_oss_midi_check_exit_p

    Veröffentlicht Aktualisiert
  6. CVE-2026-74387

    Hoch · CVSS 7.8EPSS 0,17%Korrektur verfügbar

    ALSA: seq: midi: Serialize output teardown with event_input

    In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize output teardown with event_input event_process_midi() borrows msynth->output_rfile.output and then passes the substream to dump_midi() and snd_rawmidi_kernel_write() without synchronizing with the output open/close transition. midisynth_use() also publishes output_rfile before snd_rawmidi_output_params() has finished. The last midisynth_unuse() can therefore release the same rawmidi file and free substream->runtime before snd_rawmidi_kernel_write1() takes its runtime buffer reference. That leaves the event_input path using a stale substream or ru

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  7. CVE-2026-74386

    Hoch · CVSS 8.2EPSS 0,18%Korrektur verfügbar

    nvmet-tcp: fix page fragment cache leak in error path

    In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix page fragment cache leak in error path In nvmet_tcp_alloc_queue(), when a connection is closed during the allocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN), the error handling jumps to out_destroy_sq and then to out_ida_remove without draining the page fragment cache. Although nvmet_tcp_free_cmd() is called in some error paths to release individual page fragments, the underlying page cache reference held by queue->pf_cache is never released. The first allocation using pf_cache is the call to nvmet_tcp_alloc_cmd() for queue->connect, whi

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  8. CVE-2026-74385

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

    nvmet-tcp: check return value of nvmet_tcp_set_queue_sock

    In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check return value of nvmet_tcp_set_queue_sock The return value of nvmet_tcp_set_queue_sock() is currently ignored in nvmet_tcp_tls_handshake_done(). If it fails (e.g., due to the socket not being in TCP_ESTABLISHED state), the socket callbacks will not be properly set, leading to queue and socket leakage. Fix this by capturing the return value and calling nvmet_tcp_schedule_release_queue() on failure to ensure proper cleanup.

    Veröffentlicht Aktualisiert
  9. CVE-2026-74384

    Kritisch · CVSS 9.8EPSS 0,51%Korrektur verfügbar

    nvme-multipath: fix flex array size in struct nvme_ns_head

    In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures s

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  10. CVE-2026-74382

    Nicht bewertetEPSS 0,19%Korrektur verfügbar

    net/sched: cls_bpf: prevent unbounded recursion in offload rollback

    In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a c

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  11. CVE-2026-74381

    Nicht bewertetEPSS 0,21%Korrektur verfügbar

    gpu: host1x: Allow entries in BO caches to be freed

    In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Allow entries in BO caches to be freed When a buffer object is pinned via host1x_bo_pin() with a cache, the resulting mapping is kept in the cache so it can be reused on subsequent pins. Each mapping held a reference to the underlying host1x_bo (taken in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached, the bo itself could not be freed. However, the only way to remove the cached mapping was through the free path of the buffer object. This meant that if a bo got cached, it could never get freed again. Resolve the circularity by holding a weak

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  12. CVE-2026-74380

    Hoch · CVSS 8.8EPSS 0,18%Korrektur verfügbar

    gpu: host1x: Fix iommu_map_sgtable() return value check

    In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix iommu_map_sgtable() return value check Commit "iommu: return full error code from iommu_map_sg[_atomic]()" changed iommu_map_sgtable() to return an ssize_t and negative values in error cases, rather than a size_t and a zero. pin_job() also was incorrectly assigning to 'int', which could cause overflows into negative values. Update pin_job() to correctly check for errors from iommu_map_sgtable.

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  13. CVE-2026-74379

    Nicht bewertetEPSS 0,17%Korrektur verfügbar

    dax/kmem: account for partial discontiguous resource upon removal

    In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrec

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  14. CVE-2026-74378

    Hoch · CVSS 7.8EPSS 0,14%Korrektur verfügbar

    RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe

    In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe. Read num_sge into a local variable and use it for both the bounds check and the size calculation.

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  15. CVE-2026-74377

    Hoch · CVSS 7.8EPSS 0,13%Korrektur verfügbar

    RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

    In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data(). Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and no

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  16. CVE-2026-74376

    Kritisch · CVSS 9.8EPSS 0,5%Korrektur verfügbar

    md/raid10: reset read_slot when reusing r10bio for discard

    In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.

    • Auf 6.8.0-1071.79+fips1 aktualisieren
    Veröffentlicht Aktualisiert
  17. CVE-2026-74375

    Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht

    md/raid1,raid10: fix deadlock in read error recovery path

    In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: fix deadlock in read error recovery path raid1d and raid10d may resubmit a split md cloned bio while handling a read error. In this case, resubmitting the bio can lead to a deadlock if the array is suspended before md_handle_request() acquires an active_io reference via percpu_ref_tryget_live(). Since the cloned bio already holds an active_io reference, trying to acquire another reference via percpu_ref_tryget_live() can lead to a deadlock while the array is suspended. Fix this by using percpu_ref_get() for md cloned bios.

    Veröffentlicht Aktualisiert
  18. CVE-2026-74374

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

    md/raid1,raid10: fix error-path detection with md_cloned_bio()

    In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: fix error-path detection with md_cloned_bio() Detect the error path using md_cloned_bio() instead of relying on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be NULL or -1 after splitting and resubmitting a failed bio. As a result, the error path may not be recognized and memory allocations can incorrectly use GFP_NOIO instead of (GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under memory pressure.

    Veröffentlicht Aktualisiert
  19. CVE-2026-74373

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    md/raid1,raid10: fix bio accounting for split md cloned bios

    In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: fix bio accounting for split md cloned bios Use md_cloned_bio() to control bio accounting instead of relying on r1bio_existed in raid1 or the io_accounting flag in raid10. The previous logic does not reliably reflect whether a bio is an md cloned bio. When a failed bio is split and resubmitted via bio_submit_split_bioset() on the error path, this can lead to either double accounting for md cloned bios, or missing accounting for bios returned from bio_submit_split_bioset() Fix this by using md_cloned_bio() to detect md cloned bios and skip accounting accor

    Veröffentlicht Aktualisiert
  20. CVE-2026-74368

    Mittel · CVSS 6.9EPSS 0,17%Keine Korrektur veröffentlicht

    wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()

    In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic() In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the NWIFI header length is invalid, causing the function to abort early with -EINVAL. When this happens, the error propagates to ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it to NULL. As a result, the corresponding MSDU is no longer referenced by the defragmentation path and is never freed. This leads to a memory leak for the affected MSDU on this error path. Pro

    Veröffentlicht Aktualisiert

Prüfen Sie Ihren Server

Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.

Prüfen Sie Ihren Server →