p PatchFirst

PatchFirst · Latest vulnerabilities

linux-gcp-5.15 vulnerabilities · Page 167

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

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 4254

  1. CVE-2024-35890

    High · CVSS 7.8EPSS 0.24%Fix available

    gro: fix ownership transfer

    In the Linux kernel, the following vulnerability has been resolved: gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_r

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2024-35889

    High · CVSS 8.6EPSS 0.38%Fix available

    idpf: fix kernel panic on unknown packet types

    In the Linux kernel, the following vulnerability has been resolved: idpf: fix kernel panic on unknown packet types In the very rare case where a packet type is unknown to the driver, idpf_rx_process_skb_fields would return early without calling eth_type_trans to set the skb protocol / the network layer handler. This is especially problematic if tcpdump is running when such a packet is received, i.e. it would cause a kernel panic. Instead, call eth_type_trans for every single packet, even when the packet type is unknown.

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1083.92~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2024-35888

    High · CVSS 7.3EPSS 0.61%Fix available

    erspan: make sure erspan_base_hdr is present in skb->head

    In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [i

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2024-35887

    High · CVSS 8.8EPSS 0.34%Fix available

    ax25: fix use-after-free bugs caused by ax25_ds_del_timer

    In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE |

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2024-35886

    High · CVSS 7.8EPSS 0.28%Fix available

    ipv6: Fix infinite recursion in fib6_dump_done().

    In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix infinite recursion in fib6_dump_done(). syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1] From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0] 12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8) Here, fib6_dump_done() was

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2024-35885

    Medium · CVSS 5.5EPSS 0.23%Fix available

    mlxbf_gige: stop interface during shutdown

    In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, I

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2024-35884

    Critical · CVSS 9.8EPSS 0.69%Fix available

    udp: do not accept non-tunnel GSO skbs landing in a tunnel

    In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2024-35879

    High · CVSS 7.8EPSS 0.24%Fix available

    of: dynamic: Synchronize of_changeset_destroy() with the devlink removals

    In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2024-35877

    Medium · CVSS 5.5EPSS 0.25%Fix available

    x86/mm/pat: fix VM_PAT handling in COW mappings

    In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2024-35872

    High · CVSS 7.8EPSS 0.24%Fix available

    mm/secretmem: fix GUP-fast succeeding on secretmem folios

    In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2024-35871

    High · CVSS 7.1EPSS 0.27%Fix available

    riscv: process: Fix kernel gp leakage

    In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not h

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2024-35857

    High · CVSS 7.5EPSS 0.98%Fix available

    icmp: prevent possible NULL dereferences from icmp_build_probe()

    In the Linux kernel, the following vulnerability has been resolved: icmp: prevent possible NULL dereferences from icmp_build_probe() First problem is a double call to __in_dev_get_rcu(), because the second one could return NULL. if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list) Second problem is a read from dev->ip6_ptr with no NULL check: if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list)) Use the correct RCU API to fix these. v2: add missing include <net/addrconf.h>

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2024-35855

    High · CVSS 7.8EPSS 0.23%Fix available

    mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update

    In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device. As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1]. Fix by closing the race and perform the activity query under the 'vregion->lock' mutex. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of s

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2024-35854

    High · CVSS 7.8EPSS 0.58%Fix available

    mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash

    In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash The rehash delayed work migrates filters from one region to another according to the number of available credits. The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration. The destruction of a region that still has filters referencing it can result in a use-after-free [1]. Fix by

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2024-35853

    Medium · CVSS 6.4EPSS 0.73%Fix available

    mlxsw: spectrum_acl_tcam: Fix memory leak during rehash

    In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak during rehash The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters. If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem. Each virtual chunk refere

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2024-35852

    Medium · CVSS 5.5EPSS 0.26%Fix available

    mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work

    In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2024-35851

    Medium · CVSS 5.7EPSS 0.23%Fix available

    Bluetooth: qca: fix NULL-deref on non-serdev suspend

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2024-35849

    High · CVSS 7.1EPSS 0.26%Fix available

    btrfs: fix information leak in btrfs_ioctl_logical_to_ino()

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260

    linux-gcp-5.15Operating systems
    • Update to 5.15.0-1065.73~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

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

Check your server →