In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect regression Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister().

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

  - A vulnerability was found in Linux Kernel where refcount leak in llcp_sock_bind() causing use-after-free     which might lead to privilege escalations. (CVE-2020-25670)

  - A vulnerability was found in Linux Kernel, where a refcount leak in llcp_sock_connect() causing use-after-     free which might lead to privilege escalations. (CVE-2020-25671)

  - A memory leak vulnerability was found in Linux kernel in llcp_sock_connect (CVE-2020-25672)

  - A vulnerability was found in Linux kernel where non-blocking socket in llcp_sock_connect() leads to leak     and eventually hanging-up the system. (CVE-2020-25673)

  - A race condition in Linux kernel SCTP sockets (net/sctp/socket.c) before 5.12-rc8 can lead to kernel     privilege escalation from the context of a network service or an unprivileged process. If     sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock then an element is removed from the     auto_asconf_splist list without any proper locking. This can be exploited by an attacker with network     service privileges to escalate to root or from the context of an unprivileged user directly if a     BPF_CGROUP_INET_SOCK_CREATE is attached which denies creation of some SCTP socket. (CVE-2021-23133)

  - An issue was discovered in the Linux kernel through 5.11.x. kernel/bpf/verifier.c performs undesirable     out-of-bounds speculation on pointer arithmetic, leading to side-channel attacks that defeat Spectre     mitigations and obtain sensitive information from kernel memory. Specifically, for sequences of pointer     arithmetic operations, the pointer modification performed by the first operation is not correctly     accounted for when restricting subsequent operations. (CVE-2021-29155)

  - kernel/bpf/verifier.c in the Linux kernel through 5.12.1 performs undesirable speculative loads, leading     to disclosure of stack content via side-channel attacks, aka CID-801c6058d14a. The specific concern is not     protecting the BPF stack area against speculative loads. Also, the BPF stack can contain uninitialized     data that might represent sensitive information previously operated on by the kernel. (CVE-2021-31829)

  - The eBPF RINGBUF bpf_ringbuf_reserve() function in the Linux kernel did not check that the allocated size     was smaller than the ringbuf size, allowing an attacker to perform out-of-bounds writes within the kernel     and therefore, arbitrary code execution. This issue was fixed via commit 4b81ccebaeee (bpf, ringbuf: Deny     reserve of buffers larger than ringbuf) (v5.13-rc4) and backported to the stable kernels in v5.12.4,     v5.11.21, and v5.10.37. It was introduced via 457f44363a88 (bpf: Implement BPF ring buffer and verifier     support for it) (v5.8-rc1). (CVE-2021-3489)

  - The eBPF ALU32 bounds tracking for bitwise ops (AND, OR and XOR) in the Linux kernel did not properly     update 32-bit bounds, which could be turned into out of bounds reads and writes in the Linux kernel and     therefore, arbitrary code execution. This issue was fixed via commit 049c4e13714e (bpf: Fix alu32 const     subreg bound tracking on bitwise operations) (v5.13-rc4) and backported to the stable kernels in v5.12.4,     v5.11.21, and v5.10.37. The AND/OR issues were introduced by commit 3f50f132d840 (bpf: Verifier, do     explicit ALU32 bounds tracking) (5.7-rc1) and the XOR variant was introduced by 2921c90d4718 (bpf:Fix a     verifier failure with xor) ( 5.10-rc1). (CVE-2021-3490)

  - The io_uring subsystem in the Linux kernel allowed the MAX_RW_COUNT limit to be bypassed in the     PROVIDE_BUFFERS operation, which led to negative values being usedin mem_rw when reading /proc/<PID>/mem.
    This could be used to create a heap overflow leading to arbitrary code execution in the kernel. It was     addressed via commit d1f82808877b (io_uring: truncate lengths larger than MAX_RW_COUNT on provide     buffers) (v5.13-rc1) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. It was     introduced in ddf0322db79c (io_uring: add IORING_OP_PROVIDE_BUFFERS) (v5.7-rc1). (CVE-2021-3491)

  - A flaw was found in the Linux kernel in versions before 5.12. The value of internal.ndata, in the KVM API,     is mapped to an array index, which can be updated by a user process at anytime which could lead to an out-     of-bounds write. The highest threat from this vulnerability is to data integrity and system availability.
    (CVE-2021-3501)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix null-ptr-deref during     tty device unregistration Multiple ttys try to claim the same the minor number causing a double     unregistration of the same device. The first unregistration succeeds but the next one results in a null-     ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it     immediately. The assignment is done by the caller later. But before this assignment, calls to     get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to     assign the minor number immediately after one is found to be and rename it to obtain_minor() to better     reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up     the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor()     call. (CVE-2021-46904)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect     regression Commit 8a12f8836145 (net: hso: fix null-ptr-deref during tty device unregistration) fixed the     racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on     every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor     has been released by hso_serial_tty_unregister(). (CVE-2021-46905)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Use correct permission flag for     mixed signed bounds arithmetic We forbid adding unknown scalars with mixed signed bounds due to the     spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks.
    (CVE-2021-46908)

  - In the Linux kernel, the following vulnerability has been resolved: net: Make     tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is     global and writable; writing to it in any net namespace will leak into all other net namespaces.
    tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table     (the per-netns sysctl table) with a NULL data pointer; their handlers     (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of     referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated     initializers, there is no easy way to fix up this one bad table entry. However, the data pointer     updating logic shouldn't be applied to NULL pointers anyway, so we instead force these entries to be read-     only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net     ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus     introduced a leak. Because the intent of that commit was only to know (i.e. read) which congestion     algorithms are available or allowed, this read-only solution should be sufficient. The logic added in     recent commit 31c4d2f160eb: (net: Ensure net namespace isolation of sysctls) does not and cannot check     for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL     but use other methods (.extra2) to access the struct net. (CVE-2021-46912)

  - In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix unbalanced device     enable/disable in suspend/resume pci_disable_device() called in __ixgbe_shutdown() decreases     dev->enable_cnt by 1. pci_enable_device_mem() which increases dev->enable_cnt by 1, was removed from     ixgbe_resume() in commit 6f82b2558735 (ixgbe: use generic power management). This caused unbalanced     increase/decrease. So add pci_enable_device_mem() back. Fix the following call trace. ixgbe 0000:17:00.1:
    disabling already-disabled device Call Trace: __ixgbe_shutdown+0x10a/0x1e0 [ixgbe] ixgbe_suspend+0x32/0x70     [ixgbe] pci_pm_suspend+0x87/0x160 ? pci_pm_freeze+0xd0/0xd0 dpm_run_callback+0x42/0x170
    __device_suspend+0x114/0x460 async_suspend+0x1f/0xa0 async_run_entry_fn+0x3c/0xf0     process_one_work+0x1dd/0x410 worker_thread+0x34/0x3f0 ? cancel_delayed_work+0x90/0x90 kthread+0x14c/0x170     ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 (CVE-2021-46914)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible     divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64,     use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390     Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28     [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0     net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00     00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8     00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000     RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP:
    ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000     R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
    000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]     nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280     net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321     nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch     net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598     netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0     net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec     net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810     net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae     (CVE-2021-46915)

  - In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for     seal/unseal The original patch 8c657a0590de (KEYS: trusted: Reserve TPM for seal and unseal operations)     was correct on the mailing list: https://lore.kernel.org/linux-     integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops()     in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS     based hardware. This fix puts back the lost tpm_try_get_ops() (CVE-2021-46922)

  - In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional     security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its     result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter     in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux     implements the locked_down hook with a check whether the current task's type has the corresponding     lockdown class permission (integrity or confidentiality) allowed in the policy. This means that     calling the hook when the access control decision would be ignored generates a bogus permission check and     audit record. Fix this by checking sample_type first and only calling the hook when its result would be     honored. (CVE-2021-46971)

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.117-58.216. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.4-2022-003 advisory.

  - A vulnerability was found in Linux Kernel where refcount leak in llcp_sock_bind() causing use-after-free     which might lead to privilege escalations. (CVE-2020-25670)

  - A vulnerability was found in Linux Kernel, where a refcount leak in llcp_sock_connect() causing use-after-     free which might lead to privilege escalations. (CVE-2020-25671)

  - A memory leak vulnerability was found in Linux kernel in llcp_sock_connect (CVE-2020-25672)

  - A vulnerability was found in Linux kernel where non-blocking socket in llcp_sock_connect() leads to leak     and eventually hanging-up the system. (CVE-2020-25673)

  - A race condition in Linux kernel SCTP sockets (net/sctp/socket.c) before 5.12-rc8 can lead to kernel     privilege escalation from the context of a network service or an unprivileged process. If     sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock then an element is removed from the     auto_asconf_splist list without any proper locking. This can be exploited by an attacker with network     service privileges to escalate to root or from the context of an unprivileged user directly if a     BPF_CGROUP_INET_SOCK_CREATE is attached which denies creation of some SCTP socket. (CVE-2021-23133)

  - BPF JIT compilers in the Linux kernel through 5.11.12 have incorrect computation of branch displacements,     allowing them to execute arbitrary code within the kernel context. This affects     arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c. (CVE-2021-29154)

  - An issue was discovered in the Linux kernel through 5.11.x. kernel/bpf/verifier.c performs undesirable     out-of-bounds speculation on pointer arithmetic, leading to side-channel attacks that defeat Spectre     mitigations and obtain sensitive information from kernel memory. Specifically, for sequences of pointer     arithmetic operations, the pointer modification performed by the first operation is not correctly     accounted for when restricting subsequent operations. (CVE-2021-29155)

  - kernel/bpf/verifier.c in the Linux kernel through 5.12.1 performs undesirable speculative loads, leading     to disclosure of stack content via side-channel attacks, aka CID-801c6058d14a. The specific concern is not     protecting the BPF stack area against speculative loads. Also, the BPF stack can contain uninitialized     data that might represent sensitive information previously operated on by the kernel. (CVE-2021-31829)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix null-ptr-deref during     tty device unregistration Multiple ttys try to claim the same the minor number causing a double     unregistration of the same device. The first unregistration succeeds but the next one results in a null-     ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it     immediately. The assignment is done by the caller later. But before this assignment, calls to     get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to     assign the minor number immediately after one is found to be and rename it to obtain_minor() to better     reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up     the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor()     call. (CVE-2021-46904)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect     regression Commit 8a12f8836145 (net: hso: fix null-ptr-deref during tty device unregistration) fixed the     racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on     every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor     has been released by hso_serial_tty_unregister(). (CVE-2021-46905)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible     divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64,     use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390     Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28     [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0     net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00     00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8     00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000     RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP:
    ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000     R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
    000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]     nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280     net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321     nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch     net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598     netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0     net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec     net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810     net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae     (CVE-2021-46915)

  - In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional     security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its     result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter     in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux     implements the locked_down hook with a check whether the current task's type has the corresponding     lockdown class permission (integrity or confidentiality) allowed in the policy. This means that     calling the hook when the access control decision would be ignored generates a bogus permission check and     audit record. Fix this by checking sample_type first and only calling the hook when its result would be     honored. (CVE-2021-46971)

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.232-176.381. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2021-1636 advisory.

  - An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/huge_memory.c. The     get_user_pages (aka gup) implementation, when used for a copy-on-write page, does not properly consider     the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.
    (CVE-2020-29374)

  - A race condition in Linux kernel SCTP sockets (net/sctp/socket.c) before 5.12-rc8 can lead to kernel     privilege escalation from the context of a network service or an unprivileged process. If     sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock then an element is removed from the     auto_asconf_splist list without any proper locking. This can be exploited by an attacker with network     service privileges to escalate to root or from the context of an unprivileged user directly if a     BPF_CGROUP_INET_SOCK_CREATE is attached which denies creation of some SCTP socket. (CVE-2021-23133)

  - An issue was discovered in the Linux kernel through 5.11.x. kernel/bpf/verifier.c performs undesirable     out-of-bounds speculation on pointer arithmetic, leading to side-channel attacks that defeat Spectre     mitigations and obtain sensitive information from kernel memory. Specifically, for sequences of pointer     arithmetic operations, the pointer modification performed by the first operation is not correctly     accounted for when restricting subsequent operations. (CVE-2021-29155)

  - kernel/bpf/verifier.c in the Linux kernel through 5.12.1 performs undesirable speculative loads, leading     to disclosure of stack content via side-channel attacks, aka CID-801c6058d14a. The specific concern is not     protecting the BPF stack area against speculative loads. Also, the BPF stack can contain uninitialized     data that might represent sensitive information previously operated on by the kernel. (CVE-2021-31829)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix null-ptr-deref during     tty device unregistration Multiple ttys try to claim the same the minor number causing a double     unregistration of the same device. The first unregistration succeeds but the next one results in a null-     ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it     immediately. The assignment is done by the caller later. But before this assignment, calls to     get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to     assign the minor number immediately after one is found to be and rename it to obtain_minor() to better     reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up     the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor()     call. (CVE-2021-46904)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect     regression Commit 8a12f8836145 (net: hso: fix null-ptr-deref during tty device unregistration) fixed the     racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on     every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor     has been released by hso_serial_tty_unregister(). (CVE-2021-46905)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible     divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64,     use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390     Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28     [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0     net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00     00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8     00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000     RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP:
    ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000     R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:
    000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]     nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280     net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321     nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch     net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598     netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0     net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec     net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810     net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae     (CVE-2021-46915)

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
197057	SUSE SLES12 Security Update : kernel (SUSE-SU-2024:1646-1)	Nessus	SuSE Local Security Checks	high
197055	SUSE SLES12 Security Update : kernel (SUSE-SU-2024:1643-1)	Nessus	SuSE Local Security Checks	high
197048	SUSE SLED12 / SLES12 Security Update : kernel (SUSE-SU-2024:1648-1)	Nessus	SuSE Local Security Checks	high
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
195280	EulerOS 2.0 SP10 : kernel (EulerOS-SA-2024-1570)	Nessus	Huawei Local Security Checks	high
195267	EulerOS 2.0 SP10 : kernel (EulerOS-SA-2024-1592)	Nessus	Huawei Local Security Checks	high
192487	SUSE SLES15 Security Update : kernel (SUSE-SU-2024:0926-1)	Nessus	SuSE Local Security Checks	high
192014	SUSE SLES15 Security Update : kernel (SUSE-SU-2024:0857-1)	Nessus	SuSE Local Security Checks	high
160443	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2022-001)	Nessus	Amazon Linux Local Security Checks	high
160442	Amazon Linux 2 : kernel (ALASKERNEL-5.4-2022-003)	Nessus	Amazon Linux Local Security Checks	high
149870	Amazon Linux 2 : kernel (ALAS-2021-1636)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2021-46905

medium

Tenable Plugins

high

high

high

critical

critical

high

high

high

high

high

high

high