p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-hwe-5.4 · Seite 148

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

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 7120

  1. CVE-2026-43130

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

    iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode

    In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_fl

    Veröffentlicht Aktualisiert
  2. 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
  3. 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
  4. 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
  5. CVE-2025-71274

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

    rpmsg: core: fix race in driver_override_show() and use core helper

    In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since t

    Veröffentlicht Aktualisiert
  6. CVE-2025-71273

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

    wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()

    In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band() Simplify the code by using device managed memory allocations. This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path. Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*").

    Veröffentlicht Aktualisiert
  7. CVE-2026-43119

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

    Bluetooth: hci_sync: annotate data-races around hdev->req_status

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_se

    Veröffentlicht Aktualisiert
  8. 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
  9. CVE-2026-43117

    Kritisch · CVSS 9.1EPSS 0,46%Korrektur verfügbar

    btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()

    In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.

    • Auf 5.4.0-233.253~18.04.1 aktualisieren
    Veröffentlicht Aktualisiert
  10. 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
  11. CVE-2026-43115

    Mittel · CVSS 5.6EPSS 0,15%Keine Korrektur veröffentlicht

    srcu: Use irq_work to start GP in tiny SRCU

    In the Linux kernel, the following vulnerability has been resolved: srcu: Use irq_work to start GP in tiny SRCU Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), which acquires the workqueue pool->lock. This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to: call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lock Also add irq_work_sync() to cleanup_srcu_struct() to prevent a use-after-free if a queued irq_work fires after cleanup be

    Veröffentlicht Aktualisiert
  12. 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
  13. 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
  14. 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
  15. CVE-2026-43107

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

    xfrm: account XFRMA_IF_ID in aevent size calculation

    In the Linux kernel, the following vulnerability has been resolved: xfrm: account XFRMA_IF_ID in aevent size calculation xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set. xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic. Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.

    Veröffentlicht Aktualisiert
  16. CVE-2026-43105

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

    drm/vc4: Fix memory leak of BO array in hang state

    In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.

    Veröffentlicht Aktualisiert
  17. CVE-2026-43104

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

    drm/vc4: Fix a memory leak in hang state error path

    In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.

    Veröffentlicht Aktualisiert
  18. 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
  19. CVE-2026-43093

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

    xsk: tighten UMEM headroom validation to account for tailroom and min frame

    In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.

    Veröffentlicht Aktualisiert
  20. CVE-2026-43091

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

    xfrm: Wait for RCU readers during policy netns exit

    In the Linux kernel, the following vulnerability has been resolved: xfrm: Wait for RCU readers during policy netns exit xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables.

    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 →