Amazon Linux 2：kernel (ALASKERNEL-5.10-2022-002)
high Nessus Plugin ID 160459
語系：
概要
遠端 Amazon Linux 2 主機缺少安全性更新。說明
遠端主機上安裝的核心版本早於 5.10.47-39.130。因此，會受到 ALAS2KERNEL-5.10-2022-002 公告中所提及的多個弱點影響。- 支援 Wi-Fi 保護存取 (WPA、WPA2 和 WPA3) 和「連線對等隱私權」(WEP) 的 802.11 標準不要求 (重新) 在連線至網路後，從記憶體中清除收到的片段。在正確的情況下，當其他裝置傳送使用 WEP、CCMP 或 GCMP 加密的分散框架時，這可能會遭到濫用而插入任意網路封包和/或洩漏使用者資料。
(CVE-2020-24586)
- 支援 Wi-Fi 保護存取 (WPA、WPA2 和 WPA3) 和「連線對等隱私權」(WEP) 的 802.11 標準不要求框架的所有片段都在相同的金鑰下加密。當其他裝置傳送分散框架，且 WEP、CCMP 或 GCMP 加密金鑰定期更新時，攻擊者可濫用此弱點解密所選的片段。(CVE-2020-24587)
- 支援 Wi-Fi 保護存取 (WPA、WPA2 和 WPA3) 和「連線對等隱私權」(WEP) 的 802.11 標準不要求驗證純文字 QoS 標頭欄位中的 A-MSDU 旗標。
針對支援接收非 SSP A-MSDU 框架 (在 802.11n 中是強制要求) 的裝置，攻擊者可濫用此弱點插入任意網路封包。(CVE-2020-24588)
- 在 NetBSD 7.1 核心中發現一個問題。即使傳送者尚未成功驗證 AP，存取點 (AP) 仍會將 EAPOL 框架轉送至其他用戶端。這可能會在投影的 Wi-Fi 網路中遭到濫用，進而對連線的用戶端發動拒絕服務攻擊，讓攻擊者更容易惡意利用連線用戶端中的其他弱點。(CVE-2020-26139)
- 在 AWUS036H 的 ALFA Windows 10 驅動程式 6.1316.1209 中發現一個問題。Wi-Fi 實作未驗證分散 TKIP 框架的訊息完整性檢查 (真確性)。攻擊者可濫用此弱點，在支援 TKIP 資料機密性通訊協定的 WPA 或 WPA2 網路中插入封包，並可能將封包解密。(CVE-2020-26141)
- 在 Samsung Galaxy S3 i9305 4.4.4 裝置上發現一個問題。WEP、WPA、WPA2 和 WPA3 實作會接受第二個 (或後續) 廣播片段，即使是以純文字傳送，並將其處理為完整的未分散框架。攻擊者可濫用此弱點，插入獨立於網路組態的任意網路封包。(CVE-2020-26145)
- 在 Linux 核心 5.8.9 中發現一個問題。即使部分片段是以純文字傳送，WEP、WPA、WPA2 和 WPA3 實作仍會重組片段。攻擊者可利用此弱點，在其他裝置傳送分散框架並使用 WEP、CCMP 或 GCMP 資料機密通訊協定時，插入封包和/或洩漏所選片段。(CVE-2020-26147)
- 5.8.13 及之前版本的 Linux 核心不會正確強制執行安全開機禁止簽章資料庫 (即 dbx) 保護機制。這會影響 certs/blacklist.c 和 certs/system_keyring.c。
(CVE-2020-26541)
- 藍牙核心規格 2.1 到 5.2 中的 Bluetooth LE 和 BR/EDR 安全配對可能允許附近的攔截式攻擊者透過公開金鑰的反映，識別配對期間 (在 Passkey 驗證程序中) 所使用的 Passkey 以及起始裝置的驗證證據，可能允許此攻擊者使用配對工作階段的正確 Passkey，完成與回應裝置的驗證配對。攻擊方法會以一次一位元的方式來判斷 Passkey 值。(CVE-2020-26558)
- BlueZ 中的不當存取控制可能會允許經驗證的使用者透過相鄰存取造成資訊洩漏。(CVE-2021-0129)
- 在 Linux 中發現一個問題：這是由於對 KVM 中的 VM_IO|VM_PFNMAP vmas 處理不當造成。此問題可造成使用者繞過 RO 檢查，並導致頁面在 VMM 和來賓仍可存取時遭到釋放。這讓能夠啟動和控制 VM 的使用者可以讀取/寫入隨機的記憶體頁面，並可能導致本機權限提升。(CVE-2021-22543)
- 來賓在 Linux xen-netback 中觸發釋放後使用惡意或錯誤的網路 PV 前端可強制 Linux netback 停用介面，並終止與佇列 0 相關的接收核心執行緒，以回應前端傳送格式錯誤的封包。這類核心執行緒會在後端損毀時導致 Linux netback 中出現釋放後使用情形，因為與佇列 0 相關的核心執行緒已經已結束，因此將針對過時指標執行 kthread_stop 呼叫。
(CVE-2021-28691)
- 此弱點允許本機攻擊者提升受影響 Linux 核心 5.11.15 安裝的權限。攻擊者必須先取得在目標系統上執行低權限程式碼的能力，才能攻擊此弱點。在處理 eBPF 程式時存在一個特定缺陷。此問題是因為在執行使用者提供的 eBPF 程式之前，未正確驗證這些程式所導致。
攻擊者可利用此弱點，在核心的內容中提升權限並執行任意程式碼。是 ZDI-CAN-13661。(CVE-2021-31440)
- 在 5.12.2 版之前的 Linux 核心中，net/bluetooth/hci_request.c 有移除 HCI 控制器的爭用情形。(CVE-2021-32399)
- 在 5.12.4 版之前的 Linux 核心中，net/bluetooth/hci_event.c 會在破壞 hci_chan (即 CID-5c4c8c954409) 時發生釋放後使用問題。這會導致寫入任意值。(CVE-2021-33034)
- 在 5.12.13 之前的 Linux 核心的 kernel/bpf/verifier.c 中，分支可能會發生錯誤預測 (例如，因類型混淆所致)，因此無權限的 BPF 程式可透過旁路攻擊讀取任意記憶體位置，即 CID -9183671af6db。(CVE-2021-33624)
- 5.12.10 之前的 Linux 核心中的 net/can/bcm.c 由於部分資料結構未初始化，允許本機使用者從核心堆疊記憶體取得敏感資訊。(CVE-2021-34693)
- 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)
- 在 5.12.0-rc4 之前的版本中，在 Linux 核心之 f2fs 模組的 fs/f2fs/node.c 中，發現一個超出邊界 (OOB) 記憶體存取缺陷。邊界檢查失敗允許本機攻擊者取得超出邊界存取記憶體的權限，進而導致系統損毀或內部核心資訊洩漏。此弱點對系統可用性威脅最大。(CVE-2021-3506)
- Nitro Enclaves 核心驅動程式中出現 NULL 指標解除參照缺陷，發現於 Enclaves VM 強制關閉 enclave 檔案描述符號的方式中。主機電腦的本機使用者可利用此缺陷來損毀系統或提高自己的系統權限。(CVE-2021-3543)
- 在使用者附加惡意 HCI TTY 藍牙裝置的方式中，發現 Linux 核心 HCI 裝置初始化子系統中存在一個重複釋放記憶體損毀缺陷。本機使用者可能會利用此缺陷造成系統當機。此缺陷會影響從 3.13 開始的所有 Linux 核心版本。(CVE-2021-3564)
- 在使用者呼叫 ioct HCIUNBLOCKADDR 的方式中，或是其他觸發呼叫 hci_unregister_dev() 以及呼叫 hci_sock_blacklist_add()、hci_sock_blacklist_del()、hci_get_conn_info()、hci_get_auth_info() 之一的爭用情形的方式中，發現 Linux 核心 HCI 子系統的 hci_sock_bound_ioctl() 函式中存在釋放後使用問題。有權限的本機使用者可利用此缺陷來損毀系統或提高自己的系統權限。此缺陷會影響 5.13-rc5 之前的 Linux 核心版本。(CVE-2021-3573)
- 在 Linux 核心 5.12.10 之前版本中，net/nfc/llcp_sock.c 允許無權限的本機使用者在特定類型的繫結呼叫失敗後，透過 getsockname 呼叫造成拒絕服務 (NULL 指標解除參照和 BUG)。(CVE-2021-38208)
- 在 Linux 核心中，下列弱點已解決：HID：usbhid：修復 hid_submit_ctrl 中的資訊洩漏問題。在 hid_submit_ctrl() 中，計算報告長度的方式未將 report->size 可能為零的情況納入考量。執行 syzkaller 再生器時，大小為 0 的報告會導致 hid_submit_ctrl) 將 transfer_buffer_length 計算為 16384。將此 urb 傳遞至 usb 核心層時，KMSAN 會報告 16384 位元組的資訊洩漏問題。若要修復此問題，請先修改 hid_report_len()，使用除數的 DIV_ROUND_UP 來解決報告大小為零的情況。然後再從 hid_submit_ctrl() 呼叫它。(CVE-2021-46906)
- 在 Linux 核心中，下列弱點已解決：dm rq：修正表格載入失敗後 dev remove 中 blk_mq_tag_set 的重複釋放問題。針對要求型對應裝置載入 device-mapper 表格時，裝置的 blk_mq_tag_set 失敗，後續裝置移除將造成重複釋放。例如 (dmesg)：device-mapper：核心：無法初始化要求型 dm-mq 對應裝置的佇列 device-mapper: ioctl：無法設定新表格的裝置佇列。
無法處理虛擬核心位址空間中的核心指標解除參照。位址失敗：
0305e098835de000 TEID：0305e098835de803 使用核心 ASCE 時，在家庭空間模式中發生錯誤。
AS：000000025efe0007 R3：0000000000000024 Oops：0038 ilc:3 [#1] 連結的 SMP 模組：... 多個模組 ... 支援：是，外部 CPU：0 PID：7348 通訊：multipathd Kdump：已載入 污染：GWX 5.3.18-53-default #1 SLE15-SP3 硬體名稱：IBM 8561 T01 7I2 (LPAR) Krnl PSW：0704e00180000000 000000025e368eca (kfree+ 0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code:
000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4： a7740129 brc 7,25e369126 000000025e368ed8：
[e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 呼叫追踪： [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanupx5mapped_device+0x3 dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 上次中斷事件位址： [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 核心錯誤 - 未同步：嚴重例外狀況：panic_on_oops 當 blk_mq_tag_set 在 dm_mq_init_request_queue() 中配置/初始化失敗時，系統會取消初始化/釋放，但指標不會重設為 NULL；因此，當 dev_remove() 稍後進入 dm_mq_cleanup_mapped_device() 時，它會看到指標並嘗試取消初始化並再次釋放它。透過在 dm_mq_init_request_queue() 錯誤處理中將指標設定為 NULL 來修正此問題。也在 dm_mq_cleanup_mapped_device() 中將其設定為 NULL。 (CVE-2021-46938)
- 在 Linux 核心中，下列弱點已解決：追蹤：重建 trace_clock_global()，使其絕對不會封鎖 根據報告，環形緩衝區遞迴偵測的修正會在執行暫停/恢復測試時造成機器當機。下列回溯是透過自該案例的除錯所擷取：呼叫追踪：trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 具有以下 RIP: RIP：
0010:native_queued_spin_lock_slowpath+0x69/0x200 由於遞回偵測的修正可允許在追踪時發生單一遞回，這樣會導致 trace_clock_global() 進行自旋鎖，然後再嘗試再次取得：ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {queued_spin_lock_slowpath() { /* lock taken */ (函式圖形追踪器會追踪其他內容) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ 追踪應該 *絕對不會*封鎖，因為這樣可能會導致類似上述的奇怪鎖定。重新建構 trace_clock_global() 程式碼，而不僅僅是取得鎖定，更新記錄的 prev_time 只是為了要加以使用，因為在兩個不同 CPU 上發生的兩個事件會同時呼叫，實際上哪個事件先發生並不重要。使用 trylock 抓取鎖定以便更新 prev_time，如果失敗，只需下次重試即可。如果無法取得，則表示其他項目已在更新該項目。Bugzilla：https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)
- 在 Linux 核心中，下列弱點已解決：md/raid1：結束失敗的寫入要求時正確指出失敗。此修補程式可解決使用點陣圖的 raid1 陣列中的資料損毀錯誤。若無此修正，失敗的 I/O 的點陣圖位元最終會遭到清除。由於我們處於 raid1_end_write_request 的失敗分支中，因此要求需要為重試 (R1BIO_WriteError) 或失敗 (R1BIO_Degraded) 狀態。 (CVE-2021-46950)
- 在 Linux 核心中，下列弱點已解決：NFS: fs_context：驗證 UDP 重新傳輸以防止位移超出邊界 修正 xprt_calc_majortimeo() 中的位移超出邊界。這是因為將記憶體逾時 (retrans) 掛載選項傳遞至 nfs 掛載所造成，在此情況下是從 syzkaller 傳遞。如果通訊協定是 XPRT_TRANSPORT_UDP，則「retrans」是 64 位元長整數的位移值，因此「retrans」不能 >= 64。如果 >= 64，則掛載失敗並傳回錯誤。 (CVE-2021-46952)
- 在 Linux 核心中，下列弱點已解決： ACPI: GTDT：watchdow 探查失敗時不損毀中斷對應。當因為無效的韌體內容而導致驅動程式探查失敗時，GTDT 驅動程式會取消對應其先前對應的中斷。但是，它從來不會檢查中斷的對應是否實際成功。此外，倘若韌體報告與 GIC SGI 範圍重疊的非法中斷編號，如此可能導致 IPI 對應遭到取消，以及後續的爆發事件 (如 Dann Frazier 所報告)。修改驅動程式使其行為略微正常，並在取消對應事物之前，實際檢查是否已經中斷對應。 (CVE-2021-46953)
- 在 Linux 核心中，下列弱點已解決：irqchip/gic-v3：處理假性中斷時不啟用 irqs 我們在執行 4.19 核心 (反向移植 pseudo-NMI 修補程式) 時觸發了下列錯誤：[ 14.816231] ------------[cut here ]------------ [ 14.816231] irq.c:99! 的核心錯誤[ 14.816232] 內部錯誤：Oops - BUG: 0 [#1] SMP [ 14.816232] 處理交換進程/0 (pid：
0，堆疊限制 = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: 交換進程/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] 硬體名稱：evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN
-UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28:
ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25:
00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18:
ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15:
ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 :
000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 :
0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254]
__handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle +0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] 程式碼：940587f1 d5384100 b9401001 36a7fd01 (d4210000) 14.816258連結下列的模組：start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] 核心錯誤 - 未同步：中斷中的嚴重例外狀況 [ 15.103099] SMP：停止次要 CPU [15.103100] 核心位移：已停用 [ 15.103100] CPU 功能：0x36,a2400218 [ 15.103100] 記憶體限制：
無，其由 nmi_enter() 中的「BUG_ON(in_nmi())」所造成。從呼叫追踪中，我們可以找到三個中斷 (如上文所述的 A、B、C)：中斷 (A) 由 (B) 先佔，後者進一步由 (C) 中斷。
後續調查顯示 (B) 導致 nmi_enter() 被呼叫，但實際上此為假性中斷。此外，在 (B) 的內容中會重新啟用中斷，且 (C) 會以 NMI 優先順序觸發。我們最終會遇到巢狀 NMI 情況，這是我們絕對不想 (也無法) 處理的情況。此處的錯誤是假性中斷絕不會導致任何狀態變更，我們應該僅傳回中斷的內容。儘快在 GICv3 處理程式中移動假性中斷的處理可修正此問題。[maz：重寫提交訊息，已更正 修正：標籤] (CVE-2021-46961)
- 在 Linux 核心中，下列弱點已解決： sched：修正 uclamp 中的超出邊界存取。Util-clamp 會基於效能的限制值，將工作放在不同的值區中。
不過，目前使用進位除數來計算值區的大小，這也可能在某些組態中導致差一錯誤。例如，若有 20 個值區，則值區大小將會是 1024/20=51。具有 1024 限制的工作將對應至值區 id 1024/51=20。遺憾的是，正確的索引位於 [0,19] 範圍內，因此會導致超出邊界記憶體存取。限制值區 ID 以修正此問題。
(CVE-2021-46993)
- 在 Linux 核心中，下列弱點已解決：netfilter: nftables：修正新物件中 userdata 錯誤路徑的 memleak 如果 userdata 配置失敗，則發佈物件名稱。 (CVE-2021-46996)
- 在 Linux 核心中，下列弱點已解決：mm: memcontrol: slab：修正取得釋放 memcg 修補程式系列的參照。使用 obj_cgroup API 計算 kmem 頁面，v5。從 Roman 系列開始 套用新的 cgroup slab 記憶體控制器。所有平台物件皆以 obj_cgroup 的新 API 計算。新的 API 引入了 obj_cgroup 結構以計算平台物件。這個方式可防止長期物件釘選記憶體中的原始記憶體 cgroup。但仍有部分角落物件 (例如 SLUB 中大於 order-1 頁面的配置) 未使用新的 API 計算。這些物件 (包括直接從夥伴記憶體分配器分配的頁面) 將作為仍然保留記憶體 cgroup 參照的 kmem 頁面計算。例如我們知道核心堆疊是以 kmem 頁面計算，因為核心堆疊的大小可能超過 2 個頁面 (例如 x86_64 或 arm64 上的 16KB)。如果我們建立了執行緒 (假設執行緒堆疊已經計入記憶體 cgroup A)，然後將其從記憶體 cgroup A 移動到記憶體 cgroup B。由於執行緒的核心堆疊保留了記憶體 cgroup A 的參照。執行緒可以釘選記憶體中的記憶體 cgroup A，即使我們移除 cgroup A 也是如此。如果我們想要查看此狀況，可以使用下列指令碼。我們可以看見，系統已新增 500 個終止 cgroup (這並非是實際問題，只是一個指令碼，顯示大型 kmalloc 是以 kmem 頁面計算，此方式可釘選記憶體中的記憶體 cgroup)。 #!/bin/bash cat /proc/cgroups | grep memory cd /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory 此修補程式集旨在透過使用 obj_cgroup 的 API，讓這些 kmem 頁面捨棄對記憶體 cgroup 的參照。最後我們可以看到，如果我們執行上述的測試指令碼，終止 cgroup 的數量將不會增加。此修補程式 (共 7 個)：rcu_read_lock/unlock 僅能保證 memcg 不會被釋放，但無法保證 css_get (快取的 memcg 變更時位於 refill_stock 中) 成功轉換至 memcg。 rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get 可將參照計數器從 0 變更回 1。css_get(&memcg->css) rcu_read_unlock( ) 此修正非常類似 commit: eefbfa7fd678 (mm: memcg/slab: obj_cgroup_charge 中的釋放後使用) 修正這個問題的方法是保留 memcg 的參照，該參照會在呼叫前傳送至 __memcg_kmem_uncharge()
__memcg_kmem_uncharge()。 (CVE-2021-47011)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
執行「yum update kernel」以更新系統。另請參閱
https://alas.aws.amazon.com/AL2/ALASKERNEL-5.10-2022-002.html
https://alas.aws.amazon.com/faqs.html
https://alas.aws.amazon.com/cve/html/CVE-2020-24586.html
https://alas.aws.amazon.com/cve/html/CVE-2020-24587.html
https://alas.aws.amazon.com/cve/html/CVE-2020-24588.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26139.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26141.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26145.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26147.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26541.html
https://alas.aws.amazon.com/cve/html/CVE-2020-26558.html
https://alas.aws.amazon.com/cve/html/CVE-2021-0129.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3489.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3490.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3491.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3506.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3543.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3564.html
https://alas.aws.amazon.com/cve/html/CVE-2021-3573.html
https://alas.aws.amazon.com/cve/html/CVE-2021-22543.html
https://alas.aws.amazon.com/cve/html/CVE-2021-28691.html
https://alas.aws.amazon.com/cve/html/CVE-2021-31440.html
https://alas.aws.amazon.com/cve/html/CVE-2021-32399.html
https://alas.aws.amazon.com/cve/html/CVE-2021-33034.html
https://alas.aws.amazon.com/cve/html/CVE-2021-33624.html
https://alas.aws.amazon.com/cve/html/CVE-2021-34693.html
https://alas.aws.amazon.com/cve/html/CVE-2021-38208.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46906.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46938.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46939.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46950.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46952.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46953.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46961.html
https://alas.aws.amazon.com/cve/html/CVE-2021-46993.html
Plugin 詳細資訊
嚴重性: High
ID: 160459
檔案名稱: al2_ALASKERNEL-5_10-2022-002.nasl
版本: 1.11
類型: local
代理程式: unix
已發布: 2022/5/2
已更新: 2024/4/25
支援的感應器: Agentless Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Nessus Agent, Nessus
風險資訊
VPR
風險因素: Critical
分數: 9.2
CVSS v2
風險因素: High
基本分數: 7.2
時間分數: 6.3
媒介: CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2021-3543
CVSS v3
風險因素: High
基本分數: 8.8
時間分數: 8.4
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:H/RL:O/RC:C
CVSS 評分資料來源: CVE-2021-3491
弱點資訊
CPE: p-cpe:/a:amazon:linux:bpftool, p-cpe:/a:amazon:linux:bpftool-debuginfo, p-cpe:/a:amazon:linux:kernel, p-cpe:/a:amazon:linux:kernel-debuginfo, p-cpe:/a:amazon:linux:kernel-debuginfo-common-aarch64, p-cpe:/a:amazon:linux:kernel-debuginfo-common-x86_64, p-cpe:/a:amazon:linux:kernel-devel, p-cpe:/a:amazon:linux:kernel-headers, p-cpe:/a:amazon:linux:kernel-tools, p-cpe:/a:amazon:linux:kernel-tools-debuginfo, p-cpe:/a:amazon:linux:kernel-tools-devel, p-cpe:/a:amazon:linux:perf, p-cpe:/a:amazon:linux:perf-debuginfo, p-cpe:/a:amazon:linux:python-perf, p-cpe:/a:amazon:linux:python-perf-debuginfo, cpe:/o:amazon:linux:2
必要的 KB 項目: Host/local_checks_enabled, Host/AmazonLinux/release, Host/AmazonLinux/rpm-list
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2022/1/20
弱點發布日期: 2020/10/2
可惡意利用
Core Impact
Metasploit (Linux eBPF ALU32 32-bit Invalid Bounds Tracking LPE)
參考資訊
CVE: CVE-2020-24586, CVE-2020-24587, CVE-2020-24588, CVE-2020-26139, CVE-2020-26141, CVE-2020-26145, CVE-2020-26147, CVE-2020-26541, CVE-2020-26558, CVE-2021-0129, CVE-2021-22543, CVE-2021-28691, CVE-2021-31440, CVE-2021-32399, CVE-2021-33034, CVE-2021-33624, CVE-2021-34693, CVE-2021-3489, CVE-2021-3490, CVE-2021-3491, CVE-2021-3506, CVE-2021-3543, CVE-2021-3564, CVE-2021-3573, CVE-2021-38208, CVE-2021-46906, CVE-2021-46938, CVE-2021-46939, CVE-2021-46950, CVE-2021-46952, CVE-2021-46953, CVE-2021-46961, CVE-2021-46993, CVE-2021-46996, CVE-2021-47011
IAVA: 2021-A-0222-S, 2021-A-0223-S