远程主机上安装的内核版本低于 4.14.262-200.489。因此，如公告 ALAS2-2022-1749 所述，该主机受到多个漏洞的影响。

  - 恶意后端可通过高频率事件对来宾发动 DoS 攻击 T[其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE]。Xen 能够在常规的无权限来宾（通常称为驱动程序域）中运行 PV 后端。
    在驱动程序域中运行 PV 后端有一个主要的安全优点：如果驱动程序域遭受入侵，则无权接管系统。但是，恶意驱动程序域可能会尝试通过高频发送事件来攻击其他来宾，从而导致来宾因长时间尝试中断服务而引发拒绝服务情形。有三种受影响的后端：* 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）

  - 来宾可强制 Linux netback 驱动程序独占大量内核内存 T[其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE]。Linux 内核的 netback 驱动程序中来宾的传入数据包将被缓冲，直到来宾准备好处理这些数据包。虽然可以采取一些措施来避免堆积过多数据，但客户机也可以绕过这些措施：假定接口的客户机在停止使用新数据包之前会经历一段超时时间，而且这个超时时间相当长（默认为 60 秒）。
    在快速接口上使用 UDP 连接可轻松累积若干 GB 数据。
    (CVE-2021-28715) 如果来宾能够使其 RX 队列环页面只需要一个空闲槽，而下一个数据包需要多个空闲槽，则超时甚至永远不会被触发（这可能适用使用 GSO、XDP 或软件散列的情况）。(CVE-2021-28714)（CVE-2021-28714、CVE-2021-28715）

  - 据发现，在 Linux 内核中，RDMA 在 InfiniBand 上的实现存在缺陷。向 /dev/infiniband/rdma_cm 设备节点发出命令时，拥有特权本地帐户的攻击者可泄露内核堆栈信息。尽管此访问行为不太可能泄漏敏感用户信息，但可被进一步用于破坏现有的内核保护机制。(CVE-2021-3923)

  - 在用户同时调用 close() 和 fget() 的方式中，于 Linux 内核的 Unix 域套接字文件处理程序中发现一个释放后读取内存缺陷，该缺陷可能触发争用条件。本地用户可利用此缺陷导致系统崩溃或升级其系统权限。
    此缺陷影响 5.16-rc4 之前的 Linux 内核版本。(CVE-2021-4083)

  - 在 XFS 文件系统中 XFS_IOC_ALLOCSP IOCTL 允许未对齐大小的文件增加大小的方式中发现数据泄漏缺陷。本地攻击者可利用此缺陷泄露 XFS 文件系统上其无法访问的数据。(CVE-2021-4155)

  - Linux 内核 5.15.11 及之前版本的 TEE 子系统的 drivers/tee/tee_shm.c 中存在一个释放后使用漏洞。
    原因是在尝试释放共享内存对象期间，tee_shm_get_from_id 中存在争用条件。(CVE-2021-44733)

  - 在 Linux 内核中，以下漏洞已修复：sctp：使用 call_rcu 释放端点 此补丁用于通过调用 call_rcu() 来延迟端点释放，以修复 sctp_sock_dump() 中的另一个释放后使用问题：错误：KASAN：__lock_acquire+0x36d9/0x4c20 中存在释放后使用问题 调用跟踪：
    __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 如果 asoc 被剥离且旧的 sk 在被 asoc->base.sk 获取之后和调用 lock_sock(sk) 之前被释放，则会发生此问题。
    为防止 sk 释放，作为 sk 的持有者，在调用 lock_sock() 时，ep 应该处于有效状态。此补丁使用 call_rcu() 并将 sock_put 和 ep 释放移至 sctp_endpoint_destroy_rcu()，以便安全地尝试在 sctp_transport_traverse_process() 的 rcu_read_lock 下保存 ep。如果 sctp_endpoint_hold() 返回 true，则表示此 ep 仍有效，我们已保留并可继续转储；如果返回 false，则表示此 ep 无效，可在 rcu_read_unlock 后释放，并且我们应跳过。在 sctp_sock_dump() 中，锁定 sk 之后，如果此 ep 与 tsp->asoc->ep 不同，则表示在此转储期间，此 asoc 已在调用 lock_sock() 之前剥离，因此应跳过 sk；如果此 ep 与 tsp->asoc->ep 相同，则表示此 asoc 未发生剥离，并且受 lock_sock 影响，在 release_sock 之前也不会发生剥离。请注意，延迟端点释放不会导致端口释放延迟，因为 sctp_endpoint_destroy() 中的端口释放发生在调用 call_rcu() 之前。此外，通过 call_rcu() 释放端点让 sctp_assocs_seq_show() 和 sctp_rcv() 中的 asoc->base.sk 可以安全地访问 sk。
    感谢 Jones 报告此问题。v1->v2：- 改进变更日志。- 将 kfree(ep) 添加到 sctp_endpoint_destroy_rcu() 中，正如 Jakub 注意到的那样。(CVE-2021-46929)

  - 已解决 Linux 内核中的以下漏洞：net：修复 tw_timer_handler 中的释放后使用问题。在 Linux 5.4 中发现如下真实的错误问题。BUG：无法处理以下地址的页面错误：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 自 2017 年以来，在线程 [1] 中也发现了此问题，遗憾的是，修复 DCCP 后仍可能会出现此问题。因为 tcp_sk_ops 是在 ipv4_mib_ops 之前注册，，因此当 net 命名空间被破坏时，会在调用 tcp_sk_exit_batch 之前调用 ipv4_mib_exit_net，这意味着 tcp_sk_ops 位于 pernet_list 列表中 ipv4_mib_ops 的前端。如果存在一些 inflight time-wait 定时器，则在 ipv4_mib_exit_net 之后 tw_timer_handler 中的 net->mib.net_statistics 会发生释放后使用。此缺陷并非提交 f2bf415cfed7（mib：将网络添加至 NET_ADD_STATS_BH）引入，因为 net_statistics 是全局变量，并非动态分配和释放。实际上，引入了该缺陷的是提交 61a7e26028b9（mib：将网络统计数据置于 struct net 上），因为它将网络统计数据置于 struct net 上，并在 net 命名空间被破坏时将其释放。将 init_ipv4_mibs() 移动到 tcp_init() 的前端以修复此缺陷，并将 pr_crit() 替换为 panic()，这是因为 init_ipv4_mibs() 失败时继续操作毫无意义。[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - 在 Linux 内核的 cgroup_release_agent_write 的 kernel/cgroup/cgroup-v1.c 函数中发现一个漏洞。在某些情况下，此缺陷允许使用 cgroups v1 release_agent 功能意外提升权限和绕过命名空间隔离。
    (CVE-2022-0492)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

检测

Amazon Linux 2：内核 (ALAS-2022-1749)

high Nessus 插件 ID 157408

版本 1.8