In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1

The remote Ubuntu 14.04 LTS / 16.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-6739-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free     Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit     to avoid the use after free. [wsa: added comment to the code, added Fixes tag] (CVE-2019-25162)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in     tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page     fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP:
    0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450
    __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120     apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately,     the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before     tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops,     which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-     after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some     inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (mib: add net to     NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and     freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since     it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs()     to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is     meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-
    _Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while     fragmenting IPv4 packets running openvswitch on kernels built with KASAN, it's possible to see the     following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in     ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID:
    1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS     1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1     print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111     ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400     [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150     [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490     netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0     sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170     do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90     41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00     00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50     EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX:
    00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0     R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12:
    0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address     belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0     pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122     0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped     because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at     offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) 'ovs_dst'     [192, 424) 'ovs_rt' Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00     00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00     00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00     00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment()     uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu()     ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct     rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this     changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for     IPv6 few lines below. (CVE-2021-46955)

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential     use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the     requested count is less than table.length, the allocated buffer will be freed but subsequent calls to     cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and     set the buf to NULL in the -EINVAL error path to match the rest of function. (CVE-2021-46966)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling     entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file     (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However     depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are     active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip     c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points     into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed     the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching     will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes,     because none of the patching we do is to that code or anywhere in the vicinity. (CVE-2021-46990)

  - In emulation_proc_handler of armv8_deprecated.c, there is a possible way to corrupt memory due to a race     condition. This could lead to local escalation of privilege with no additional execution privileges     needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid     ID: A-237540956References: Upstream kernel (CVE-2022-20422)

  - A data race flaw was found in the Linux kernel, between where con is allocated and con->sock is set. This     issue leads to a NULL pointer dereference when accessing con->sock->sk in net/tipc/topsrv.c in the tipc     protocol in the Linux kernel. (CVE-2023-1382)

  - The Linux kernel allows userspace processes to enable mitigations by calling prctl with     PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed     that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to     attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be     observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened     because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that     STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection.
    However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons,     which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target     injection against which STIBP protects. (CVE-2023-1998)

  - Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core     Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and     might lead to discovery of the encryption key and live injection, aka BLUFFS. (CVE-2023-24023)

  - In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race     condition between a nonblocking atomic commit and a driver unload. (CVE-2023-51043)

  - bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free     because of a bt_sock_ioctl race condition. (CVE-2023-51779)

  - dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in     alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct     dm_ioctl.target_count. (CVE-2023-52429)

  - In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on     context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func     function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that     might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check     before the invalid read reported by syzbot, within the context disconnection call stack. (CVE-2023-52445)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access     beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb     array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the     cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid     entry in the array. The debug message at the end of the function then dereferences this pointer:
    pr_debug(Failed to hot-remove memory at %llx\n, lmb->base_addr); This was found by inspection and     confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234     ================================================================== BUG: KASAN: slab-out-of-bounds in     dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949     dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0
    __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0     kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390     vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530     system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80     kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320     kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0     kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy     address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072     The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000,     c000000364e97fd0) ================================================================== pseries-hotplug-mem:
    Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor     only when it points to a valid entry. (CVE-2023-52451)

  - In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When     the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in     diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when     diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. (CVE-2023-52600)

  - In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in     dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN:
    array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot     [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware     name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK>
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue     lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900     fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80     fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013     do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat     fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00     00 00 0f 1f 40 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246     ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX:
    0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000     R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13:
    0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of     fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was     able to produce value less than -1 which cause the error. This patch simply add the change for the values     less than 0. The patch is tested via syzbot. (CVE-2023-52603)

  - copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than     INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to     ctl_ioctl. (CVE-2024-23851)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of kernel installed on the remote host is prior to 5.10.93-87.444. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.10-2022-009 advisory.

  - Rogue backends can cause DoS of guests via high frequency events T[his CNA information record relates to     multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen offers the     ability to run PV backends in regular unprivileged guests, typically referred to as driver domains.
    Running PV backends in driver domains has one primary security advantage: if a driver domain gets     compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain     could try to attack other guests via sending events at a high frequency leading to a Denial of Service in     the guest due to trying to service interrupts for elongated amounts of time. There are three affected     backends: * blkfront patch 1, CVE-2021-28711 * netfront patch 2, CVE-2021-28712 * hvc_xen (console) patch     3, CVE-2021-28713 (CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

  - Guest can force Linux netback driver to hog large amounts of kernel memory T[his CNA information record     relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]     Incoming data packets for a guest in the Linux kernel's netback driver are buffered until the guest is     ready to process them. There are some measures taken for avoiding to pile up too much data, but those can     be bypassed by the guest: There is a timeout how long the client side of an interface can stop consuming     new packets before it is assumed to have stalled, but this timeout is rather long (60 seconds by default).
    Using a UDP connection on a fast interface can easily accumulate gigabytes of data in that time.
    (CVE-2021-28715) The timeout could even never trigger if the guest manages to have only one free slot in     its RX queue ring page and the next package would require more than one free slot, which may be the case     when using GSO, XDP, or software hashing. (CVE-2021-28714) (CVE-2021-28714, CVE-2021-28715)

  - A flaw was found in the Linux kernel's implementation of RDMA over infiniband. An attacker with a     privileged local account can leak kernel stack information when issuing commands to the     /dev/infiniband/rdma_cm device node. While this access is unlikely to leak sensitive user information, it     can be further used to defeat existing kernel protection mechanisms. (CVE-2021-3923)

  - A memory leak vulnerability was found in the Linux kernel's eBPF for the Simulated networking device     driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called. A     local user could use this flaw to get unauthorized access to some data. (CVE-2021-4135)

  - A data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size     increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS     filesystem otherwise not accessible to them. (CVE-2021-4155)

  - In the Linux kernel through 5.15.2, hw_atl_utils_fw_rpc_wait in     drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c allows an attacker (who can introduce a     crafted device) to trigger an out-of-bounds write via a crafted length value. (CVE-2021-43975)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint     This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in     sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace:
    __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520     kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
    _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334     [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774     lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324     sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
    __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065     netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0     net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline]     inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232     [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440     net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc     is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).
    To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch     uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try     to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns     true, it means this ep is still alive and we have held it and can continue to dump it; If it returns     false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In     sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this     dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is     the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff     will happen either until release_sock. Note that delaying endpoint free won't delay the port release, as     the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by     call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
    Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into     sctp_endpoint_destroy_rcu(), as Jakub noticed. (CVE-2021-46929)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Wrap the tx reporter dump     callback to extract the sq Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct     mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct     mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1     enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last     trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is     00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95     Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),     BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work     [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace:
    mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0     devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ?     mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]     ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? pick_next_task_fair+0x227/0x340 ?     finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] process_one_work+0x1de/0x3a0     worker_thread+0x2d/0x3c0 ? process_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90     ret_from_fork+0x1f/0x30 --[ end trace 51ccabea504edaff ]--- RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180     PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled end Kernel panic - not     syncing: Fatal exception To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the     sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback.
    (CVE-2021-46931)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: validate user data in compat     ioctl Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to     trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported     warnings (CVE-2021-46934)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in     tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page     fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP:
    0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450
    __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120     apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately,     the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before     tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops,     which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-     after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some     inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (mib: add net to     NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and     freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since     it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs()     to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is     meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-
    _Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem     Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in     case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local     user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to     legacy handling) could use this flaw to escalate their privileges on the system. (CVE-2022-0185)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of kernel installed on the remote host is prior to 5.4.172-90.336. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.4-2022-021 advisory.

  - Rogue backends can cause DoS of guests via high frequency events T[his CNA information record relates to     multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen offers the     ability to run PV backends in regular unprivileged guests, typically referred to as driver domains.
    Running PV backends in driver domains has one primary security advantage: if a driver domain gets     compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain     could try to attack other guests via sending events at a high frequency leading to a Denial of Service in     the guest due to trying to service interrupts for elongated amounts of time. There are three affected     backends: * blkfront patch 1, CVE-2021-28711 * netfront patch 2, CVE-2021-28712 * hvc_xen (console) patch     3, CVE-2021-28713 (CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

  - Guest can force Linux netback driver to hog large amounts of kernel memory T[his CNA information record     relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]     Incoming data packets for a guest in the Linux kernel's netback driver are buffered until the guest is     ready to process them. There are some measures taken for avoiding to pile up too much data, but those can     be bypassed by the guest: There is a timeout how long the client side of an interface can stop consuming     new packets before it is assumed to have stalled, but this timeout is rather long (60 seconds by default).
    Using a UDP connection on a fast interface can easily accumulate gigabytes of data in that time.
    (CVE-2021-28715) The timeout could even never trigger if the guest manages to have only one free slot in     its RX queue ring page and the next package would require more than one free slot, which may be the case     when using GSO, XDP, or software hashing. (CVE-2021-28714) (CVE-2021-28714, CVE-2021-28715)

  - A flaw was found in the Linux kernel's implementation of RDMA over infiniband. An attacker with a     privileged local account can leak kernel stack information when issuing commands to the     /dev/infiniband/rdma_cm device node. While this access is unlikely to leak sensitive user information, it     can be further used to defeat existing kernel protection mechanisms. (CVE-2021-3923)

  - A memory leak vulnerability was found in the Linux kernel's eBPF for the Simulated networking device     driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called. A     local user could use this flaw to get unauthorized access to some data. (CVE-2021-4135)

  - A data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size     increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS     filesystem otherwise not accessible to them. (CVE-2021-4155)

  - In the Linux kernel through 5.15.2, hw_atl_utils_fw_rpc_wait in     drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c allows an attacker (who can introduce a     crafted device) to trigger an out-of-bounds write via a crafted length value. (CVE-2021-43975)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint     This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in     sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace:
    __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520     kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
    _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334     [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774     lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324     sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
    __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065     netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0     net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline]     inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232     [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440     net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc     is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).
    To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch     uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try     to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns     true, it means this ep is still alive and we have held it and can continue to dump it; If it returns     false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In     sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this     dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is     the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff     will happen either until release_sock. Note that delaying endpoint free won't delay the port release, as     the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by     call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
    Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into     sctp_endpoint_destroy_rcu(), as Jakub noticed. (CVE-2021-46929)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: validate user data in compat     ioctl Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to     trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported     warnings (CVE-2021-46934)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in     tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page     fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP:
    0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450
    __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120     apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately,     the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before     tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops,     which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-     after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some     inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (mib: add net to     NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and     freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since     it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs()     to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is     meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-
    _Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - A heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem     Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in     case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local     user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to     legacy handling) could use this flaw to escalate their privileges on the system. (CVE-2022-0185)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of kernel installed on the remote host is prior to 4.14.262-200.489. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2022-1749 advisory.

  - Rogue backends can cause DoS of guests via high frequency events T[his CNA information record relates to     multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen offers the     ability to run PV backends in regular unprivileged guests, typically referred to as driver domains.
    Running PV backends in driver domains has one primary security advantage: if a driver domain gets     compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain     could try to attack other guests via sending events at a high frequency leading to a Denial of Service in     the guest due to trying to service interrupts for elongated amounts of time. There are three affected     backends: * blkfront patch 1, CVE-2021-28711 * netfront patch 2, CVE-2021-28712 * hvc_xen (console) patch     3, CVE-2021-28713 (CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

  - Guest can force Linux netback driver to hog large amounts of kernel memory T[his CNA information record     relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]     Incoming data packets for a guest in the Linux kernel's netback driver are buffered until the guest is     ready to process them. There are some measures taken for avoiding to pile up too much data, but those can     be bypassed by the guest: There is a timeout how long the client side of an interface can stop consuming     new packets before it is assumed to have stalled, but this timeout is rather long (60 seconds by default).
    Using a UDP connection on a fast interface can easily accumulate gigabytes of data in that time.
    (CVE-2021-28715) The timeout could even never trigger if the guest manages to have only one free slot in     its RX queue ring page and the next package would require more than one free slot, which may be the case     when using GSO, XDP, or software hashing. (CVE-2021-28714) (CVE-2021-28714, CVE-2021-28715)

  - A flaw was found in the Linux kernel's implementation of RDMA over infiniband. An attacker with a     privileged local account can leak kernel stack information when issuing commands to the     /dev/infiniband/rdma_cm device node. While this access is unlikely to leak sensitive user information, it     can be further used to defeat existing kernel protection mechanisms. (CVE-2021-3923)

  - A read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket     file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race     condition. This flaw allows a local user to crash the system or escalate their privileges on the system.
    This flaw affects Linux kernel versions prior to 5.16-rc4. (CVE-2021-4083)

  - A data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size     increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS     filesystem otherwise not accessible to them. (CVE-2021-4155)

  - A use-after-free exists in drivers/tee/tee_shm.c in the TEE subsystem in the Linux kernel through 5.15.11.
    This occurs because of a race condition in tee_shm_get_from_id during an attempt to free a shared memory     object. (CVE-2021-44733)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint     This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in     sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace:
    __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520     kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
    _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334     [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774     lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324     sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
    __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065     netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0     net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline]     inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232     [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440     net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc     is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).
    To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch     uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try     to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns     true, it means this ep is still alive and we have held it and can continue to dump it; If it returns     false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In     sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this     dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is     the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff     will happen either until release_sock. Note that delaying endpoint free won't delay the port release, as     the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by     call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
    Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into     sctp_endpoint_destroy_rcu(), as Jakub noticed. (CVE-2021-46929)

  - In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in     tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page     fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP:
    0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450
    __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120     apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately,     the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before     tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops,     which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-     after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some     inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (mib: add net to     NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and     freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since     it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs()     to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is     meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-
    _Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - A vulnerability was found in the Linux kernel's cgroup_release_agent_write in the     kernel/cgroup/cgroup-v1.c function. This flaw, under certain circumstances, allows the use of the cgroups     v1 release_agent feature to escalate privileges and bypass the namespace isolation unexpectedly.
    (CVE-2022-0492)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
195662	RHEL 6 : kernel (Unpatched Vulnerability)	Nessus	Red Hat Local Security Checks	critical
195652	RHEL 7 : kernel (Unpatched Vulnerability)	Nessus	Red Hat Local Security Checks	critical
194976	SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1490-1)	Nessus	SuSE Local Security Checks	high
194886	SUSE SLED15 / SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1480-1)	Nessus	SuSE Local Security Checks	high
194745	SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1466-1)	Nessus	SuSE Local Security Checks	high
193594	Ubuntu 14.04 LTS / 16.04 LTS : Linux kernel vulnerabilities (USN-6739-1)	Nessus	Ubuntu Local Security Checks	high
193454	SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:1322-1)	Nessus	SuSE Local Security Checks	high
193453	SUSE SLES15 Security Update : kernel (SUSE-SU-2024:1321-1)	Nessus	SuSE Local Security Checks	high
160451	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2022-009)	Nessus	Amazon Linux Local Security Checks	high
160423	Amazon Linux 2 : kernel (ALASKERNEL-5.4-2022-021)	Nessus	Amazon Linux Local Security Checks	high
157408	Amazon Linux 2 : kernel (ALAS-2022-1749)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2021-46936

high

Tenable Plugins

critical

critical

high

high

high

high

high

high

high

high

high