p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-fips · Seite 92

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

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 5130

  1. CVE-2026-43135

    Mittel · CVSS 5.5EPSS 0,12%Keine Korrektur veröffentlicht

    media: cx23885: Add missing unmap in snd_cx23885_hw_params()

    In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().

    Veröffentlicht Aktualisiert
  2. CVE-2026-43134

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

    Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.

    Veröffentlicht Aktualisiert
  3. CVE-2026-43126

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

    ALSA: mixer: oss: Add card disconnect checkpoints

    In the Linux kernel, the following vulnerability has been resolved: ALSA: mixer: oss: Add card disconnect checkpoints ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device. For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly.

    Veröffentlicht Aktualisiert
  4. CVE-2026-43124

    Mittel · CVSS 5.5EPSS 0,13%Keine Korrektur veröffentlicht

    pstore: ram_core: fix incorrect success return when vmap() fails

    In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures.

    Veröffentlicht Aktualisiert
  5. CVE-2026-43123

    Mittel · CVSS 5.5EPSS 0,13%Keine Korrektur veröffentlicht

    fbcon: check return value of con2fb_acquire_newinfo()

    In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    Veröffentlicht Aktualisiert
  6. CVE-2026-43118

    Mittel · CVSS 5.5EPSS 0,16%Keine Korrektur veröffentlicht

    btrfs: fix zero size inode with non-zero size after log replay

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix zero size inode with non-zero size after log replay When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents). This works fine except when we have already logged an inode in full mo

    Veröffentlicht Aktualisiert
  7. CVE-2026-43116

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

    netfilter: ctnetlink: ensure safe access to master conntrack

    In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch g

    Veröffentlicht Aktualisiert
  8. CVE-2026-43113

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

    wifi: wl1251: validate packet IDs before indexing tx_frames

    In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

    Veröffentlicht Aktualisiert
  9. CVE-2026-43111

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

    HID: roccat: fix use-after-free in roccat_report_event

    In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.

    Veröffentlicht Aktualisiert
  10. CVE-2026-43110

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

    wifi: brcmfmac: validate bsscfg indices in IF events

    In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]

    Veröffentlicht Aktualisiert
  11. CVE-2026-43103

    Mittel · CVSS 5.5EPSS 0,12%Keine Korrektur veröffentlicht

    net: lapbether: handle NETDEV_PRE_TYPE_CHANGE

    In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.

    Veröffentlicht Aktualisiert
  12. CVE-2026-43089

    Mittel · CVSS 5.5EPSS 0,13%Keine Korrektur veröffentlicht

    xfrm_user: fix info leak in build_mapping()

    In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

    Veröffentlicht Aktualisiert
  13. CVE-2026-43088

    Mittel · CVSS 5.5EPSS 0,12%Keine Korrektur veröffentlicht

    net: af_key: zero aligned sockaddr tail in PF_KEY exports

    In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_p

    Veröffentlicht Aktualisiert
  14. CVE-2026-43085

    Mittel · CVSS 5.5EPSS 0,13%Keine Korrektur veröffentlicht

    netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(),

    Veröffentlicht Aktualisiert
  15. CVE-2026-43080

    Mittel · CVSS 5.5EPSS 0,12%Keine Korrektur veröffentlicht

    l2tp: Drop large packets with UDP encap

    In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4,

    Veröffentlicht Aktualisiert
  16. CVE-2026-43076

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

    ocfs2: validate inline data i_size during inode read

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typicall

    Veröffentlicht Aktualisiert
  17. CVE-2026-43075

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

    ocfs2: fix out-of-bounds write in ocfs2_write_end_inline

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline da

    Veröffentlicht Aktualisiert
  18. CVE-2026-43073

    Mittel · CVSS 5.5EPSS 0,16%Keine Korrektur veröffentlicht

    x86-64: rename misleadingly named '__copy_user_nocache()' function

    In the Linux kernel, the following vulnerability has been resolved: x86-64: rename misleadingly named '__copy_user_nocache()' function This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quad

    Veröffentlicht Aktualisiert
  19. CVE-2026-43071

    Kritisch · CVSS 9.1EPSS 0,46%Keine Korrektur veröffentlicht

    dcache: Limit the minimal number of bucket to two

    In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_

    Veröffentlicht Aktualisiert
  20. CVE-2026-43068

    Mittel · CVSS 5.5EPSS 0,12%Keine Korrektur veröffentlicht

    ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()

    In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ... EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 w

    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 →