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: netfilter: nf_tables: fully validate
    NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional,
    however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper
    function to infer the register type from the set datatype so this conditional check can be removed.
    Otherwise, pointer to chain object can be leaked through the registers. (CVE-2024-42070)

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: md: fix kmemleak of rdev->serial If
    kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak
    occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex
    dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>]
    kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>]
    __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>]
    rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>]
    bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>]
    md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>]
    vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>]
    do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 (CVE-2024-26900)

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: dyndbg: fix old BUG_ON in >control
    parser Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by
    removing it, doing pr_err and return -EINVAL instead. (CVE-2024-35947)

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: bpf: Take return from set_memory_ro()
    into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its
    return and take it into account as an error. (CVE-2024-42068)

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: blk-iocost: avoid out of bounds shift
    UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number
    that is too large, resulting in undefined behavior on some architectures. [ 186.556576] ------------[ cut
    here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large
    for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N
    6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes
    Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0
    __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80
    __run_timer_base+0x1b6/0x250 ... Avoid that undefined behavior by simply taking the "delay = 0" branch if
    the shift is too large. I am not sure what the symptoms of an undefined value delay will be, but I suspect
    it could be more than a little annoying to debug. (CVE-2024-36916)

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: nfsd: fix RELEASE_LOCKOWNER The test
    on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(),
    changing that to not sleep. First: harmful. As is documented in the kdoc comment for
    nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a
    return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with
    the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other
    thread is still processing a LOCK request which failed because, at the time that request was received, the
    given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a
    reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error.
    The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER
    without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was
    in fact released so it feels free to use the same lock owner identifier in some later locking request.
    When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a
    lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger
    lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive,
    which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count
    is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs
    locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is
    tested against '2' it is clear that one of these is the transient reference obtained by
    find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count
    is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my
    testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before
    RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded
    (it is removed when there are no more references which usually happens when the lock state is discarded).
    When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case
    shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client
    uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2'
    is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the
    (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls
    nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks()
    rather than testing so_count against the mysterious '2'. (CVE-2024-26629)

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: ipv6: fib6_rules: avoid possible NULL
    dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe
    ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general
    protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-
    executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute
    Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action
    net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code:
    02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b
    48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP:
    0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
    RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08:
    ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
    R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000)
    GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790
    net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
    ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93
    [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180
    net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
    sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0
    net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
    __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline]
    sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline]
    __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect
    net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 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 (CVE-2024-36902)

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: nfs: Handle error of
    rpc_proc_register() in nfs_net_init(). syzkaller reported a warning [0] triggered while destroying
    immature netns. rpc_proc_register() was called in init_nfs_fs(), but its error has been ignored since at
    least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recently, commit d47151b79e32 ("nfs: expose
    /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more
    visible. Even when rpc_proc_register() fails, nfs_net_init() could succeed, and thus nfs_net_exit() will
    be called while destroying the netns. Then, remove_proc_entry() will be called for non-existing proc
    directory and trigger the warning below. Let's handle the error of rpc_proc_register() properly in
    nfs_net_init(). [0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711
    remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-
    executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX,
    1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP:
    0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88
    58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09
    b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX:
    0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045
    RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10:
    0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc
    R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010
    DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpc_proc_unregister+0x64/0x70
    net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0
    net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590
    net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
    unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322
    __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline]
    __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP:
    0033:0x7f30d0febe5d 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 73 9f 1b 00 f7 d8 64 89
    01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX:
    00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
    </TASK> (CVE-2024-36939)

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: bpf, skmsg: Fix NULL pointer
    dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue()
    which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write
    to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257
    [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline]
    sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048
    __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660
    fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline]
    __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541
    do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by
    task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline]
    sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0
    net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
    sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline]
    unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220
    net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec
    net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410
    net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
    __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0
    entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported
    by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W
    6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in
    sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready.
    Here is another different caller causing the same issue because of the same reason. So we should protect
    it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses
    "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two
    pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. (CVE-2024-36938)

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
427936	Bottlerocket: kernel-5.15, kernel-6.1: security update to 2.3.0	medium
427935	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427934	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427933	Bottlerocket: kernel-5.15, kernel-6.1: security update to 2.3.0	medium
427932	Bottlerocket: kernel-5.15: security update to 2.1.0	high
427931	Bottlerocket: kernel-5.10: security update to 2.2.0	medium
427930	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427929	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
427928	Bottlerocket: kernel-5.15: security update to 2.1.0	medium
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

medium

medium

medium

medium

high

medium

medium

medium

medium

high

high

high

medium

medium

high

high

medium

high

medium

high

medium

medium

medium

medium