There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net: sched: flower: protect fl_walk()
    with rcu Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul() also removed rcu
    protection of individual filters which causes following use-after-free when filter is deleted
    concurrently. Fix fl_walk() to obtain rcu read lock while iterating and taking the filter reference and
    temporary release the lock while calling arg->fn() callback that can sleep. KASAN trace: [ 352.773640]
    ================================================================== [ 352.775041] BUG: KASAN: use-after-
    free in fl_walk+0x159/0x240 [cls_flower] [ 352.776304] Read of size 4 at addr ffff8881c8251480 by task
    tc/2987 [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2 [ 352.778980] Hardware name:
    QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [
    352.781022] Call Trace: [ 352.781573] dump_stack_lvl+0x46/0x5a [ 352.782332]
    print_address_description.constprop.0+0x1f/0x140 [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower] [
    352.784292] ? fl_walk+0x159/0x240 [cls_flower] [ 352.785138] kasan_report.cold+0x83/0xdf [ 352.785851] ?
    fl_walk+0x159/0x240 [cls_flower] [ 352.786587] kasan_check_range+0x145/0x1a0 [ 352.787337]
    fl_walk+0x159/0x240 [cls_flower] [ 352.788163] ? fl_put+0x10/0x10 [cls_flower] [ 352.789007] ?
    __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.790102] tcf_chain_dump+0x231/0x450 [ 352.790878] ?
    tcf_chain_tp_delete_empty+0x170/0x170 [ 352.791833] ? __might_sleep+0x2e/0xc0 [ 352.792594] ?
    tfilter_notify+0x170/0x170 [ 352.793400] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.794477]
    tc_dump_tfilter+0x385/0x4b0 [ 352.795262] ? tc_new_tfilter+0x1180/0x1180 [ 352.796103] ?
    __mod_node_page_state+0x1f/0xc0 [ 352.796974] ? __build_skb_around+0x10e/0x130 [ 352.797826]
    netlink_dump+0x2c0/0x560 [ 352.798563] ? netlink_getsockopt+0x430/0x430 [ 352.799433] ?
    __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.800542] __netlink_dump_start+0x356/0x440 [
    352.801397] rtnetlink_rcv_msg+0x3ff/0x550 [ 352.802190] ? tc_new_tfilter+0x1180/0x1180 [ 352.802872] ?
    rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.803668] ? tc_new_tfilter+0x1180/0x1180 [ 352.804344] ?
    _copy_from_iter_nocache+0x800/0x800 [ 352.805202] ? kasan_set_track+0x1c/0x30 [ 352.805900]
    netlink_rcv_skb+0xc6/0x1f0 [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0 [ 352.807455] ?
    rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.808324] ? netlink_ack+0x4d0/0x4d0 [ 352.809086] ?
    netlink_deliver_tap+0x62/0x3d0 [ 352.809951] netlink_unicast+0x353/0x480 [ 352.810744] ?
    netlink_attachskb+0x430/0x430 [ 352.811586] ? __alloc_skb+0xd7/0x200 [ 352.812349]
    netlink_sendmsg+0x396/0x680 [ 352.813132] ? netlink_unicast+0x480/0x480 [ 352.813952] ?
    __import_iovec+0x192/0x210 [ 352.814759] ? netlink_unicast+0x480/0x480 [ 352.815580]
    sock_sendmsg+0x6c/0x80 [ 352.816299] ____sys_sendmsg+0x3a5/0x3c0 [ 352.817096] ? kernel_sendmsg+0x30/0x30
    [ 352.817873] ? __ia32_sys_recvmmsg+0x150/0x150 [ 352.818753] ___sys_sendmsg+0xd8/0x140 [ 352.819518] ?
    sendmsg_copy_msghdr+0x110/0x110 [ 352.820402] ? ___sys_recvmsg+0xf4/0x1a0 [ 352.821110] ?
    __copy_msghdr_from_user+0x260/0x260 [ 352.821934] ? _raw_spin_lock+0x81/0xd0 [ 352.822680] ?
    __handle_mm_fault+0xef3/0x1b20 [ 352.823549] ? rb_insert_color+0x2a/0x270 [ 352.824373] ?
    copy_page_range+0x16b0/0x16b0 [ 352.825209] ? perf_event_update_userpage+0x2d0/0x2d0 [ 352.826190] ?
    __fget_light+0xd9/0xf0 [ 352.826941] __sys_sendmsg+0xb3/0x130 [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20
    [ 352.828377] ? do_user_addr_fault+0x2c5/0x8a0 [ 352.829184] ? fpregs_assert_state_consistent+0x52/0x60 [
    352.830001] ? exit_to_user_mode_prepare+0x32/0x160 [ 352.830845] do_syscall_64+0x35/0x80 [ 352.831445]
    entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.832331] RIP: 0033:0x7f7bee973c17 [ ---truncated---
    (CVE-2021-47402)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net: fix out-of-bounds access in
    ops_init net_alloc_generic is called by net_alloc, which is called without any locking. It reads
    max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then
    to set s.len, which is later used to limit the bounds of the array access. It is possible that the array
    is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then
    used to set s.len with a larger than allocated length for the variable array. Fix it by reading
    max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in
    net_assign_generic. (CVE-2024-36883)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race
    __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to
    possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).
    Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the
    wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the
    three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check
    against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various
    callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the
    blamed commit, using UDP sockets. (CVE-2024-36971)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: xdp: use flags field to disambiguate
    broadcast redirect When redirecting a packet using XDP, the bpf_redirect_map() helper will set up the
    redirect destination information in struct bpf_redirect_info (using the __bpf_xdp_redirect_map() helper
    function), and the xdp_do_redirect() function will read this information after the XDP program returns and
    pass the frame on to the right redirect destination. When using the BPF_F_BROADCAST flag to do multicast
    redirect to a whole map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct bpf_redirect_info to
    point to the destination map to be broadcast. And xdp_do_redirect() reacts to the value of this map
    pointer to decide whether it's dealing with a broadcast or a single-value redirect. However, if the
    destination map is being destroyed before xdp_do_redirect() is called, the map pointer will be cleared out
    (by bpf_clear_redirect_map()) without waiting for any XDP programs to stop running. This causes
    xdp_do_redirect() to think that the redirect was to a single target, but the target pointer is also NULL
    (since broadcast redirects don't have a single target), so this causes a crash when a NULL pointer is
    passed to dev_map_enqueue(). To fix this, change xdp_do_redirect() to react directly to the presence of
    the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info to disambiguate between a
    single-target and a broadcast redirect. And only read the 'map' pointer if the broadcast flag is set,
    aborting if that has been cleared out in the meantime. This prevents the crash, while keeping the atomic
    (cmpxchg-based) clearing of the map pointer itself, and without adding any more checks in the non-
    broadcast fast path. (CVE-2024-36937)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Correct nested
    IFLA_VF_VLAN_LIST attribute validation Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
    struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct
    ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4
    bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too
    small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read
    access when accessing the saved (casted) entry in ivvl. (CVE-2024-36017)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: sched/psi: Fix use-after-free in
    ep_remove_wait_queue() If a non-root cgroup gets removed when there is a thread that registered trigger
    and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following
    path: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release
    psi_trigger_destroy However, the polling thread still has a reference to the pressure file and will access
    the freed waitqueue when the file is closed or upon exit: fput ep_eventpoll_release ep_free
    ep_remove_wait_queue remove_wait_queue This results in use-after-free as pasted below. The fundamental
    problem here is that cgroup_file_release() (and consequently waitqueue's lifetime) is not tied to the
    file's real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the
    comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue's lifetime is not tied
    to file's one and can be considered as another special case. While this would be fixable by somehow making
    cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher
    layer which might be more justifiable if we identify more cases like this. BUG: KASAN: use-after-free in
    _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404 CPU: 19 PID:
    4404 Comm: a.out Not tainted 6.2.0-rc6 #38 Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
    Call Trace: <TASK> dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0
    kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0xc0 remove_wait_queue+0x1a/0xa0
    ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170
    do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch_do_signal_or_restart+0x2a/0x2b0
    exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x52/0x90
    entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Allocated by task 4404: kasan_set_track+0x3d/0x60
    __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 pressure_write+0x146/0x2e0
    cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/0x220 vfs_write+0x3d8/0x5c0
    ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 4407:
    kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x11d/0x170
    slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/0x180 psi_trigger_destroy+0x2e8/0x310
    cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0
    __kernfs_remove+0x1fb/0x310 kernfs_remove_by_name_ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700
    cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/0x140 vfs_rmdir+0xfe/0x240
    do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90
    entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2023-52707)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: pinctrl: core: delete incorrect free
    in pinctrl_enable() The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_
    managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead
    to a double free. The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as
    well. (CVE-2024-36940)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix possible NULL
    dereference in amdgpu_ras_query_error_status_helper() Return invalid error code -EINVAL for invalid block
    id. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper()
    error: we previously assumed 'info' could be null (see line 1176) (CVE-2023-52585)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack
    poison We found below OOB crash: [ 33.452494]
    ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-
    bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by
    task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [
    33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c
    [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from
    print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report
    from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset
    from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from
    tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [
    33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from
    rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [
    33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset
    112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame
    has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [
    33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8
    refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [
    33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw:
    00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory
    state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [
    33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2
    f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04
    f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978]
    ================================================================== We find the root cause of this OOB is
    that arm does not clear stale stack poison in the case of cpuidle. This patch refer to
    arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions
    which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this
    poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code.
    Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs
    lose context and return to the kernel via a cold path, we restore a prior context saved in
    __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by
    functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout)
    subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats
    to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a
    CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64:
    kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with
    CONFIG_KASAN_STACK") (CVE-2024-36906)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix refcount leak
    in pinctrl_dt_to_map() If we fail to allocate propname buffer, we need to drop the reference count we just
    took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly.
    (CVE-2024-36959)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in
    tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice
    analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"),
    inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the
    bucket lock. Thus, there is a small race window where other threads could try to reuse the port during
    connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that
    happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow,
    triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use
    refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]:
    refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25
    refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
    Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS
    VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff
    0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8
    7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60
    EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8
    RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09:
    ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20
    R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000)
    knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3:
    000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ?
    refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ?
    report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ?
    exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110
    tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ?
    __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0
    inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170
    entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00
    00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296
    ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX:
    0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000
    R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13:
    ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK> (CVE-2024-36904)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for
    TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections,
    mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in
    tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling
    tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() TCP_SYN_SENT
    TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 To fix this issue, change
    tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
    When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at
    sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state. This
    means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations. [1] divide
    error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted
    6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute
    Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code:
    e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29
    c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP:
    0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08:
    ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
    R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000)
    GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK>
    tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
    inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline]
    sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg
    net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018
    [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline]
    __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
    0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48
    89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89
    01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX:
    0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
    RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11:
    0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
    (CVE-2024-36905)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: net: core: reject skb_copy(_expand)
    for fraglist GSO skbs SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return
    NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential
    later call to skb_gso_segment. (CVE-2024-36929)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - A flaw was found in the filelock_init in fs/locks.c function in the Linux kernel. This issue can lead to
    host memory exhaustion due to memcg not limiting the number of Portable Operating System Interface (POSIX)
    file locks. (CVE-2022-0480)

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: nsh: Restore
    skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats
    (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
    ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and
    MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls
    skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the
    original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original
    skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up
    skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set
    ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header
    + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After
    6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped
    when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),
    skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or
    Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While
    restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in
    the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header
    accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the
    middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the
    end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH
    header. To do that, let's calculate the outer header position relatively from the inner header and set
    skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound
    drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3
    drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0
    drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
    ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0
    drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222
    __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit
    include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline]
    dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351
    dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
    sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline]
    __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto
    net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64
    arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819
    [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline]
    __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
    __ ---truncated--- (CVE-2024-36933)

ID	Name	Severity
427927	Bottlerocket: kernel-5.10: security update to 2.1.0	high
427926	Bottlerocket: kernel-5.15: security update to 2.1.0	high
427925	Bottlerocket: kernel-5.10, kernel-6.1: security update to 2.1.0	high
427924	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427923	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427922	Bottlerocket: kernel-5.10: security update to 2.1.0	high
427921	Bottlerocket: kernel-5.15: security update to 2.1.0	high
427920	Bottlerocket: kernel-5.10: security update to 2.1.0	medium
427919	Bottlerocket: kernel-5.15: security update to 2.1.0	high
427918	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427917	Bottlerocket: kernel-5.15: security update to 2.1.0	high
427916	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427915	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427914	Bottlerocket: kernel-5.10: security update to 2.1.0	medium
427913	Bottlerocket: kernel-5.15: security update to 2.1.0	medium

Detections

Analytics

Bottlerocket Local Security Checks Family for Tenable Cloud Security

high

high

high

medium

medium

high

high

medium

high

medium

high

medium

medium

medium

medium