p PatchFirst

PatchFirst · Latest vulnerabilities

linux vulnerabilities · Page 131

Vulnerabilities published for linux in the last 30 days: 700. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 15216

  1. CVE-2026-72170

    High · CVSS 7.8EPSS 0.17%Fix available

    9p: skip nlink update in cacheless mode to fix WARN_ON

    In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode's nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client's v9fs_remove() completes successfully

    • Update to 6.1.187-1
    Published Updated
  2. CVE-2026-72168

    Medium · CVSS 5.4EPSS 0.21%No fix published

    mtd: maps: vmu-flash: fix fault in unaligned fixup

    In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.

    Published Updated
  3. CVE-2026-72167

    Not ratedEPSS 0.21%Fix available

    mtd: rawnand: pl353: fix probe resource allocation

    In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.

    • Update to 6.1.180-1
    Published Updated
  4. CVE-2026-72166

    Not ratedEPSS 0.22%Fix available

    net/9p: fix infinite loop in p9_client_rpc on fatal signal

    In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(

    • Update to 6.1.180-1
    Published Updated
  5. CVE-2026-72164

    High · CVSS 7.8EPSS 0.17%Fix available

    ocfs2: avoid moving extents to occupied clusters

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode

    • Update to 6.1.180-1
    Published Updated
  6. CVE-2026-72163

    Not ratedEPSS 0.22%Fix available

    ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The

    • Update to 6.1.180-1
    Published Updated
  7. CVE-2026-72162

    High · CVSS 7.8EPSS 0.16%No fix published

    ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec [BUG] On-disk corruption setting l_next_free_rec to 0 in an inode's embedded extent list triggers a UBSAN panic on the next write to that file. [CAUSE] ocfs2_sum_rightmost_rec() computes i = le16_to_cpu(el->l_next_free_rec) - 1 and accesses el->l_recs[i] without validating i. When l_next_free_rec is 0, i becomes -1; when l_next_free_rec exceeds l_count, i falls past the end of the array. Either case violates the __counted_by_le(l_count) annotation on l_recs[] and triggers UBSAN. [FIX] Validate the inode

    Published Updated
  8. CVE-2026-72161

    Not ratedEPSS 0.21%Fix available

    ocfs2: add journal NULL check in ocfs2_checkpoint_inode()

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: add journal NULL check in ocfs2_checkpoint_inode() During unmount, ocfs2_journal_shutdown() frees the journal and sets osb->journal to NULL. Later, when VFS evicts remaining cached inodes, ocfs2_evict_inode() -> ocfs2_clear_inode() -> ocfs2_checkpoint_inode() -> ocfs2_ci_fully_checkpointed() dereferences osb->journal, causing a NULL pointer dereference. Fix this by adding a NULL check for osb->journal in ocfs2_checkpoint_inode(). If the journal is NULL, it has already been fully flushed and destroyed during shutdown, so there is nothing to checkpoint.

    • Update to 6.1.180-1
    Published Updated
  9. CVE-2026-72160

    High · CVSS 8.8EPSS 0.65%Fix available

    ocfs2: reject dinodes with non-canonical i_mode type

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories uncondit

    • Update to 6.1.180-1
    Published Updated
  10. CVE-2026-72159

    Not ratedEPSS 0.22%Fix available

    ocfs2: reject non-inline dinodes with i_size and zero i_clusters

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing s

    • Update to 6.1.180-1
    Published Updated
  11. CVE-2026-72157

    High · CVSS 8.8EPSS 0.35%Fix available

    net: thunderbolt: Fix frags[] overflow by bounding frame_count

    In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, hdr_size, frame_size, TBNET_RX_PAGE_SIZE - hdr_size); A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer

    • Update to 6.1.187-1
    Published Updated
  12. CVE-2026-72156

    Not ratedEPSS 0.21%Fix available

    fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header()

    In the Linux kernel, the following vulnerability has been resolved: fpga: microchip-spi: fix zero header_size OOB read in mpf_ops_parse_header() mpf_ops_parse_header() reads header_size from the bitstream at MPF_HEADER_SIZE_OFFSET (24). When header_size is zero, the expression *(buf + header_size - 1) reads one byte before the buffer start. Since initial_header_size is set to 71 in mpf_ops, the fpga-mgr core guarantees the buffer is large enough to reach MPF_HEADER_SIZE_OFFSET. The only real gap is the zero header_size case, which cannot be resolved by providing a larger buffer, so return -EINVAL.

    • Update to 6.1.180-1
    Published Updated
  13. CVE-2026-72155

    Not ratedEPSS 0.22%Fix available

    mtd: spi-nor: swp: Improve locking user experience

    In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: swp: Improve locking user experience In the case of the first block being locked (or the few first blocks), if the user want to fully unlock the device it has two possibilities: - either it asks to unlock the entire device, and this works; - or it asks to unlock just the block(s) that are currently locked, which fails. It fails because the conditions "can_be_top" and "can_be_bottom" are true. Indeed, in this case, we unlock everything, so the TB bit does not matter. However in the current implementation, use_top would be true (as this is the favourite optio

    • Update to 6.1.180-1
    Published Updated
  14. CVE-2026-72153

    Not ratedEPSS 0.22%Fix available

    irqchip/crossbar: Use correct index in crossbar_domain_free()

    In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number an

    • Update to 6.1.180-1
    Published Updated
  15. CVE-2026-72152

    Not ratedEPSS 0.22%Fix available

    tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()

    In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat() wait_event_interruptible_timeout() evaluates its condition after setting the current task state to TASK_INTERRUPTIBLE. With CONFIG_DEBUG_ATOMIC_SLEEP this triggers a warning when the IRQ wait path is used: tpm_tis_status() tpm_tis_spi_read_bytes() tpm_tis_spi_transfer_full() spi_bus_lock() mutex_lock() Address this with the following measures: 1. Call wait_tpm_stat_cond() only while tasking is running. 2. Use wait_woken() to wait for changes.

    • Update to 6.1.180-1
    Published Updated
  16. CVE-2026-72149

    High · CVSS 7.5EPSS 0.65%Fix available

    dmaengine: tegra: Fix burst size calculation

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra: Fix burst size calculation Currently, the Tegra GPC DMA hardware requires the transfer length to be a multiple of the max burst size configured for the channel. When a client requests a transfer where the length is not evenly divisible by the configured max burst size, the DMA hangs with partial burst at the end. Fix this by reducing the burst size to the largest power-of-2 value that evenly divides the transfer length. For example, a 40-byte transfer with a 16-byte max burst will now use an 8-byte burst (40 / 8 = 5 complete bursts) instead of causing a h

    • Update to 6.1.180-1
    Published Updated
  17. CVE-2026-72148

    High · CVSS 8.8EPSS 0.33%Fix available

    dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and ABORT_INT_MASK

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and ABORT_INT_MASK The DONE_INT_MASK and ABORT_INT_MASK registers are shared by all DMA channels, and modifying them requires a read-modify-write sequence. Because this operation is not atomic, concurrent calls to dw_edma_v0_core_start() can introduce race conditions if two channels update these registers simultaneously. Add a spinlock to serialize access to these registers and prevent race conditions. [den: update dw_edma.lock comment]

    • Update to 6.1.180-1
    Published Updated
  18. CVE-2026-72147

    Not ratedEPSS 0.21%No fix published

    dmaengine: dw-edma-pcie: Reject devices without driver data

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.

    Published Updated
  19. CVE-2026-72146

    High · CVSS 8.4EPSS 0.18%Fix available

    dmaengine: sh: rz-dmac: Move interrupt request after everything is set up

    In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().

    • Update to 6.1.187-1
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →