p PatchFirst

PatchFirst · Latest vulnerabilities

linux-gcp-5.15 vulnerabilities · Page 119

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

Filter vulnerabilities
Clear filters

Vulnerabilities: 4254

  1. CVE-2024-50167

    Medium · CVSS 5.5EPSS 0.25%Fix available

    be2net: fix potential memory leak in be_xmit()

    In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  2. CVE-2024-50163

    Medium · CVSS 5.5EPSS 0.22%Fix available

    bpf: Make sure internal and UAPI bpf_redirect flags don't overlap

    In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure i

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  3. CVE-2024-50162

    Critical · CVSS 9.8EPSS 0.52%Fix available

    bpf: devmap: provide rxq after redirect

    In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC("xdp") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC("xdp/devmap") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  4. CVE-2024-50160

    Medium · CVSS 5.5EPSS 0.22%Fix available

    ALSA: hda/cs8409: Fix possible NULL dereference

    In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  5. CVE-2024-50156

    Medium · CVSS 5.5EPSS 0.22%Fix available

    drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()

    In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since "dump_addr" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-po

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  6. CVE-2024-50154

    Critical · CVSS 9.8EPSS 0.56%Fix available

    tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

    In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race w

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  7. CVE-2024-50153

    Medium · CVSS 5.5EPSS 0.26%Fix available

    scsi: target: core: Fix null-ptr-deref in target_alloc_device()

    In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_d

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  8. CVE-2024-50151

    High · CVSS 7.8EPSS 0.28%Fix available

    smb: client: fix OOBs when building SMB2_IOCTL request

    In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  9. CVE-2024-50150

    High · CVSS 7.8EPSS 0.24%Fix available

    usb: typec: altmode should keep reference to parent

    In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0'

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  10. CVE-2024-50148

    Medium · CVSS 5.5EPSS 0.26%Fix available

    Bluetooth: bnep: fix wild-memory-access in proto_unregister

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: <TASK> __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource.

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  11. CVE-2024-50143

    High · CVSS 7.8EPSS 0.28%Fix available

    udf: fix uninit-value use in udf_get_fileshortad

    In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  12. CVE-2024-50142

    Medium · CVSS 5.5EPSS 0.26%Fix available

    xfrm: validate new SA's prefixlen using SA family when sel.family is unset

    In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since th

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  13. CVE-2024-50141

    High · CVSS 7.8EPSS 0.25%Fix available

    ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

    In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  14. CVE-2024-50134

    Medium · CVSS 5.5EPSS 0.25%Fix available

    drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA

    In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_sha

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  15. CVE-2024-50131

    High · CVSS 7.3EPSS 0.25%Fix available

    tracing: Consider the NULL character when validating the event length

    In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  16. CVE-2024-50128

    High · CVSS 7.8EPSS 0.23%Fix available

    net: wwan: fix global oob in wwan_rtnl_policy

    In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by t

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  17. CVE-2024-50127

    High · CVSS 7.8EPSS 0.25%Fix available

    net: sched: fix use-after-free in taprio_change()

    In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  18. CVE-2024-50121

    High · CVSS 7.8EPSS 0.23%Fix available

    nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net

    In the Linux kernel, the following vulnerability has been resolved: nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net In the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`, the function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will release all resources related to the hashed `nfs4_client`. If the `nfsd_client_shrinker` is running concurrently, the `expire_client` function will first unhash this client and then destroy it. This can lead to the following warning. Additionally, numerous use-after-free errors may occur as well. nfsd_client_shrinker echo 0 > /proc/fs/nfsd/threads expi

    • Update to 5.15.0-1081.90~20.04.1
    Published Updated
  19. CVE-2024-50117

    High · CVSS 7.3EPSS 0.25%Fix available

    drm/amd: Guard against bad data for ATIF ACPI method

    In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated
  20. CVE-2024-50116

    Medium · CVSS 5.5EPSS 0.24%Fix available

    nilfs2: fix kernel bug due to missing clearing of buffer delay flag

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing

    • Update to 5.15.0-1077.86~20.04.1
    Published Updated

Check your server

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

Check your server →