p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-fips · Seite 88

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

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 8179

  1. CVE-2026-72160

    Hoch · CVSS 8.8EPSS 0,65%Keine Korrektur veröffentlicht

    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

    Veröffentlicht Aktualisiert
  2. CVE-2026-72159

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    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

    Veröffentlicht Aktualisiert
  3. CVE-2026-72157

    Hoch · CVSS 8.8EPSS 0,35%Keine Korrektur veröffentlicht

    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

    Veröffentlicht Aktualisiert
  4. CVE-2026-72155

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    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

    Veröffentlicht Aktualisiert
  5. CVE-2026-72153

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    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

    Veröffentlicht Aktualisiert
  6. CVE-2026-72152

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    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.

    Veröffentlicht Aktualisiert
  7. CVE-2026-72148

    Hoch · CVSS 8.8EPSS 0,33%Keine Korrektur veröffentlicht

    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]

    Veröffentlicht Aktualisiert
  8. CVE-2026-72147

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    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.

    Veröffentlicht Aktualisiert
  9. CVE-2026-72144

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

    platform/x86: dell-laptop: fix missing cleanups in init error path

    In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-laptop: fix missing cleanups in init error path dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier. If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error. Add the missing cleanup calls before tearing down rfkill.

    Veröffentlicht Aktualisiert
  10. CVE-2026-72142

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)

    In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->

    Veröffentlicht Aktualisiert
  11. CVE-2026-72138

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    xen/gntdev: fix error handling in ioctl

    In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by

    Veröffentlicht Aktualisiert
  12. CVE-2026-72136

    Hoch · CVSS 8.8EPSS 0,17%Keine Korrektur veröffentlicht

    xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink

    In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.

    Veröffentlicht Aktualisiert
  13. CVE-2026-72135

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

    tpm: Make the TPM character devices non-seekable

    In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through

    Veröffentlicht Aktualisiert
  14. CVE-2026-72133

    Hoch · CVSS 8.4EPSS 0,18%Keine Korrektur veröffentlicht

    spi: uniphier: Fix completion initialization order before devm_request_irq()

    In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.

    Veröffentlicht Aktualisiert
  15. CVE-2026-72129

    Kritisch · CVSS 9.8EPSS 0,71%Keine Korrektur veröffentlicht

    nvmet-rdma: handle inline data with a nonzero offset

    In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: sg->offset = off; sg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to

    Veröffentlicht Aktualisiert
  16. CVE-2026-72122

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

    can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure

    In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silent

    Veröffentlicht Aktualisiert
  17. CVE-2026-72118

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    can: bcm: fix CAN frame rx/tx statistics

    In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx

    Veröffentlicht Aktualisiert
  18. CVE-2026-72117

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()

    In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex

    Veröffentlicht Aktualisiert
  19. CVE-2026-72116

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

    can: bcm: fix stale rx/tx ops after device removal

    In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic tra

    Veröffentlicht Aktualisiert
  20. CVE-2026-72115

    Hoch · CVSS 8.1EPSS 0,3%Keine Korrektur veröffentlicht

    can: bcm: track a single source interface for ANYDEV timeout/throttle ops

    In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields

    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 →