遠端主機上安裝的核心版本早於 5.10.35-31.135。因此，會受到 ALAS2KERNEL-5.10-2022-001 公告中所提及的多個弱點影響。

  - 在 Linux 核心中發現一個弱點，其中 llcp_sock_bind() 中的 refcount 洩漏會導致釋放後使用，可能進而造成權限提升。(CVE-2020-25670)

  - 在 Linux 核心中發現一個弱點，其中 llcp_sock_connect() 中的 refcount 洩漏會導致釋放後使用，可能進而造成權限提升。(CVE-2020-25671)

  - 在 llcp_sock_connect 的 Linux 核心中發現一個記憶體洩漏弱點 (CVE-2020-25672)

  - 在 Linux 核心中發現一個弱點，其中 llcp_sock_connect() 中的非封鎖通訊端會造成洩漏，並最終導致系統當機。(CVE-2020-25673)

  - 在 5.12-rc8 版之前的 Linux 核心 SCTP 通訊端 (net/sctp/socket.c) 中有一個爭用弱點，可導致核心權限從網路服務內容或無權限的處理程序提升。如果在沒有 sock_net(sk)->sctp.addr_wq_lock 的情況下呼叫 sctp_destroy_sock，則會在沒有任何適當鎖定的情況下，從 auto_asconf_splist 清單中移除元素。如果附加了拒絕建立某些 SCTP 通訊端的 BPF_CGROUP_INET_SOCK_CREATE，具有網路服務權限的攻擊者便可利用此弱點，升級至 root 權限或從無權限使用者的內容直接提升權限。(CVE-2021-23133)

  - 在 5.11.x 版之前的所有 Linux 核心中發現一個問題。kernel/bpf/verifier.c 會對指標算術執行非預期的超出邊界推測，從而導致旁路攻擊，這可以破壞 Spectre 緩解措施並從核心記憶體取得敏感資訊。具體而言，針對指標算術作業的序列，限制後續作業時，未正確考量第一個作業執行的指標修改。(CVE-2021-29155)

  - 在 Linux 核心 5.12.1 之前的所有版本中，kernel/bpf/verifier.c 會執行非預期的推測加載，透過側信道攻擊可造成堆棧內容洩漏，即 CID-801c6058d14a。具體的問題是未針對推測負載保護 BPF 堆疊區域。此外，BPF 堆疊可能包含未初始化的資料，而這些資料可能是之前由核心操作的敏感資訊。(CVE-2021-31829)

  - Linux 核心中的 eBPF RINGBUF bpf_ringbuf_reserve() 函式未檢查配置的大小是否小於 ringbuf 大小，進而允許攻擊者在核心內執行超出邊界寫入，進而導致任意程式碼執行。此問題已透過 commit 4b81ccebaeee 修復 (bpf、ringbuf：拒絕保留大於 ringbuf 的緩衝區) (v5.13-rc4)，並反向移植至 v5.12.4、v5.11.21 和 v5.10.37 中的穩定核心。這是透過 457f44363a88 引入 (bpf：建置 BPF 環形緩衝區及其驗證程式支援) (v5.8-rc1)。(CVE-2021-3489)

  - Linux 核心中位元運算 (AND、OR 和 XOR) 的 eBPF ALU32 邊界追蹤未正確更新 32 位元邊界，這會在 Linux 核心中變成越界讀取和寫入，因此造成任意程式碼執行。此問題已透過 commit 049c4e13714e 修復 (bpf：修復位元運算上的 alu32 const subreg 邊界追蹤) (v5.13-rc4)，並反向移植至 v5.12.4、v5.11.21 和 v5.10.37 中的穩定核心。AND/OR 問題是由 commit 3f50f132d840 引入 (bpf：驗證程式，執行明確 ALU32 邊界追踪) (5.7-rc1)，而 XOR 變體是由 2921c90d4718 (bpf：透過 xor 修復驗證程式失敗) ( 5.10-rc1) 引入。(CVE-2021-3490)

  - Linux 核心中的 io_uring 子系統允許在 PROVIDE_BUFFERS 作業中繞過 MAX_RW_COUNT 限制，進而導致讀取 /proc/<PID>/mem 時在 mem_rw 中使用負值。
    這可用來建立導致核心中任意程式碼執行的堆積溢位。已透過 commit d1f82808877b 解決 (io_uring：在提供緩衝區上截斷大於 MAX_RW_COUNT 的長度) (v5.13-rc1)，並反向移植至 v5.12.4、v5.11.21 和 v5.10.37 中的穩定核心。這是在 ddf0322db79c (io_uring：新增 IORING_OP_PROVIDE_BUFFERS) (v5.7-rc1) 中引入。(CVE-2021-3491)

  - 在 Linux 核心 5.12 之前的版本中發現一個缺陷。KVM API 中的 internal.ndata 值對應陣列索引，而此陣列索引可隨時透過使用者處理程序來更新，可能會因此導致超出邊界寫入。此弱點對完整性及系統可用性的威脅最大。
    (CVE-2021-3501)

  - 在 Linux 核心中，下列弱點已解決：net：hso：修復 tty 裝置取消註冊期間的 null-ptr-deref 多個 tty 嘗試宣告相同的次要編號，進而造成相同裝置雙重取消註冊。第一個取消註冊成功，但下一個取消註冊會導致 null-ptr-deref。get_free_serial_index() 函式會傳回可用的次要編號，但不會立即指派。指派稍後會由呼叫者完成。但在此指派之前，get_free_serial_index() 呼叫會傳回相同的次要號碼。修復此問題的方式為修改 get_free_serial_index，使其在發現次要編號之後立即指派次要編號，並將其重新命名為 gets_minor() 以更好地反映其作用。同樣，請將 set_serial_by_index() 重新命名為 release_minor() 並進行修改，以釋放指定 hso_serial 的次要編號。每個 acquire_minor() 都應該有對應的 release_minor() 呼叫。(CVE-2021-46904)

  - 在 Linux 核心中，下列弱點已解決：net：hso：修復中斷連線回歸提交 8a12f8836145 時的 NULL-deref (net：hso：修復 tty 裝置取消註冊期間的 null-ptr-deref)，修復 syzbot 報告的 racy 次要配置，但改為在每次中斷連線時引入無條件的 NULL 指標解除參照。具體而言，在 hso_serial_tty_unregister() 發佈次要項目之後，就不得再存取序列裝置表。(CVE-2021-46905)

  - 在 Linux 核心中，下列弱點已解決：bpf：針對混合簽署的邊界算術使用正確的權限旗標 由於 spectre v1 遮罩緩解措施，我們禁止使用混合簽署的邊界新增未知數量。因此，這也需要 bypass_spec_v1 旗標，而非 allow_ptr_leaks。
    (CVE-2021-46908)

  - 在 Linux 核心中，下列弱點已解決：net：在非 init netns 中將 tcp_allowed_congestion_control 設為唯讀 目前來說，tcp_allowed_congestion_control 具有全域性並且可寫入；在任何網路命名空間中將其寫入都會洩漏至所有其他網路命名空間。
    tcp_available_congestion_control 和 tcp_allowed_congestion_control 是 ipv4_net_table (per-netns sysctl 表格) 中唯一具有 NULL 資料指標的 sysctl；其處理程式 (proc_tcp_available_congestion_control 和 proc_allowed_congestion_control) 沒有其他參照結構網路的方式。因此，它們在全域範圍內運作。由於 ipv4_net_table 不使用指定的初始化程式，因此沒有簡單的方法可修正這個錯誤的表格項目。不過，資料指標更新邏輯無論如何都不應套用至 NULL 指標，因此我們改為強制這些項目為唯讀。這些 sysctl 曾經存在於 ipv4_table (僅限 init-net) 中，但後來被移至 per-net ipv4_net_table，而這有可能並未意識到 tcp_allowed_congestion_control 是可寫入的，因此造成了洩漏。由於該認可的目的只是為了知道 (即讀取) 哪些壅塞演算法可用或允許，因此這個唯讀解決方案應該已足夠。在最近提交 31c4d2f160eb 中新增的邏輯：(net：確保 sysctls 的網路命名空間隔離) 不會也無法檢查 NULL 資料指標，因為其他表格項目 (例如 /proc/sys/net/netfilter/nf_log/) 具有 .data= NULL，但是使用其他方法 (.extra2) 存取結構網路。 (CVE-2021-46912)

  - 在 Linux 核心中，下列弱點已解決：ixgbe：修正暫停/繼續 pci_disable_device() (已呼叫 in __ixgbe_shutdown() ) 不平衡裝置啟用/停用會將 dev->enable_cnt 減 1。 pci_enable_device_mem() 會將 dev->enable_cnt 加 1，並且從 commit 6f82b2558735 中的 ixgbe_resume() 移除 (ixgbe：使用一般電源管理)。這會造成不平衡的增加/減少。因此將 pci_enable_device_mem() 重新加回。修正下列呼叫追踪。ixgbe 0000:17:00.1:
    停用已停用的裝置 呼叫追踪：__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)

  - 在 Linux 核心中，下列弱點已解決：netfilter：nft_limit：避免 nft_limit_init div_u64() 將 u64 除以 u32 中可能發生的除法錯誤。 nft_limit_init() 想要以 u64 除以 u64，使用適當的數學函式 (div64_u64) 除錯誤：0000 [#1] PREEMPT SMP KASAN CPU：1 PID：8390 Comm：syz-executor188 未污染 5.12.0-rc4-syzkaller #0 硬體名稱：Google Google Compute Engine/Google Compute Engine、BIOS Google 01/01/2011 RIP：0010:div_u64_rem include/linux/math64.h:28 [內嵌] RIP：0010:div_u64 include/linux/math64.h：127 [內嵌] RIP：0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 程式碼：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 [內嵌] 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 [內嵌] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [內嵌] 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 [ 內嵌] 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)

  - 在 Linux 核心中，下列弱點已解決：KEYS: trusted：修正 seal/unseal 的 TPM 保留 原始修補程式 8c657a0590de (KEYS: trusted：保留 TPM 用於 seal 和 unseal 作業) 已經在郵寄清單中更正：https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ 但是因為某些原因重新定位，導致 tpm2_seal_trusted() 中的 tpm_try_get_ops() 遺失。如此造成 TPM ops 放置不平衡，並造成 TIS 型硬體發生錯誤。此修正會還原遺失的 tpm_try_get_ops() (CVE-2021-46922)

  - 在 Linux 核心中，下列弱點已解決： perf/core：修正無條件的 security_locked_down() 呼叫 目前，系統會無條件查詢鎖定狀態，即使只有在 attr.sample_type 中設定 PERF_SAMPLE_REGS_INTR 位元時才會使用其結果。雖然這在 Lockdown LSM 的情況下無關緊要，但它會造成 SELinux 的鎖定勾點實作發生問題。SELinux 實作 locked_down 勾點，檢查目前工作的類型是否具有原則所允許的對應鎖定類別權限 (完整性或機密性)。這表示在存取控制決策將遭到忽略時呼叫勾點會產生假的權限檢查和稽核記錄。修正此問題的方式為先檢查 sample_type，並只在會接受其結果時呼叫勾點。 (CVE-2021-46971)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

Amazon Linux 2：kernel (ALASKERNEL-5.10-2022-001)

high Nessus Plugin ID 160443

版本 1.11