p PatchFirst

PatchFirst · Latest vulnerabilities

linux-aws-5.15 vulnerabilities · Page 179

Vulnerabilities published for linux-aws-5.15 in the last 30 days: 0. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 4238

  1. CVE-2024-26885

    High · CVSS 7.8EPSS 0.25%Fix available

    bpf: Fix DEVMAP_HASH overflow check on 32-bit arches

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  2. CVE-2024-26884

    High · CVSS 7.8EPSS 0.25%Fix available

    bpf: Fix hashtab overflow check on 32-bit arches

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  3. CVE-2024-26883

    High · CVSS 7.8EPSS 0.25%Fix available

    bpf: Fix stackmap overflow check on 32-bit arches

    In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this,

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  4. CVE-2024-26882

    High · CVSS 7.3EPSS 0.69%Fix available

    net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()

    In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  5. CVE-2024-26881

    High · CVSS 7.5EPSS 0.69%Fix available

    net: hns3: fix kernel crash when 1588 is received on HIP08 devices

    In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  6. CVE-2024-26880

    High · CVSS 7.8EPSS 0.72%Fix available

    dm: call the resume method on internal suspend

    In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  7. CVE-2024-26879

    Medium · CVSS 5.5EPSS 0.22%Fix available

    clk: meson: Add missing clocks to axg_clk_regmaps

    In the Linux kernel, the following vulnerability has been resolved: clk: meson: Add missing clocks to axg_clk_regmaps Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70 [ 57.4559

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  8. CVE-2024-26878

    Medium · CVSS 4.7EPSS 0.19%Fix available

    quota: Fix potential NULL pointer dereference

    In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a tempo

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  9. CVE-2024-26877

    Critical · CVSS 9.8EPSS 0.73%Fix available

    crypto: xilinx - call finalize with bh disabled

    In the Linux kernel, the following vulnerability has been resolved: crypto: xilinx - call finalize with bh disabled When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  10. CVE-2024-26875

    Medium · CVSS 6.4EPSS 0.25%Fix available

    media: pvrusb2: fix uaf in pvr2_context_set_notify

    In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_a

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  11. CVE-2024-26874

    Medium · CVSS 5.6EPSS 0.24%Fix available

    drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip

    In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush:

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  12. CVE-2024-26872

    High · CVSS 7.8EPSS 0.24%Fix available

    RDMA/srpt: Do not register event handler until srpt device is fully setup

    In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  13. CVE-2024-26870

    High · CVSS 7.8EPSS 0.28%Fix available

    NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102

    In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  14. CVE-2024-26863

    Medium · CVSS 5.5EPSS 0.25%Fix available

    hsr: Fix uninit-value access in hsr_get_node()

    In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  15. CVE-2024-26862

    Medium · CVSS 4.7EPSS 0.21%Fix available

    packet: annotate data-races around ignore_outgoing

    In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  16. CVE-2024-26861

    Medium · CVSS 6.3EPSS 0.18%Fix available

    wireguard: receive: annotate data-race around receiving_counter.counter

    In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  17. CVE-2024-26859

    Medium · CVSS 4.7EPSS 0.18%Fix available

    net/bnx2x: Prevent access to a freed page in page_pool

    In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  18. CVE-2023-52644

    Medium · CVSS 6.3EPSS 0.23%Fix available

    wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

    In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  19. CVE-2024-26857

    High · CVSS 7.3EPSS 0.61%Fix available

    geneve: make sure to pull inner header in geneve_rx()

    In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drive

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated
  20. CVE-2024-26856

    High · CVSS 8.8EPSS 0.32%Fix available

    net: sparx5: Fix use after free inside sparx5_del_mact_entry

    In the Linux kernel, the following vulnerability has been resolved: net: sparx5: Fix use after free inside sparx5_del_mact_entry Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it.

    • Update to 5.15.0-1063.69~20.04.1
    Published Updated

Check your server

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

Check your server →