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

    2024-05-23：已將 CVE-2022-20166 新增至此公告。

    2024-04-25：已將 CVE-2021-46936 新增至此公告。

    2024-04-25：已將 CVE-2021-46929 新增至此公告。

    2024-04-25：已將 CVE-2021-46934 新增至此公告。

    2023-10-12：已將 CVE-2021-3923 新增至此公告。

    在 Linux 核心的 Xen hypervisor 子系統中，發現虛擬機器客體存在拒絕服務缺陷，此缺陷與使用者從其中一個客體呼叫某些高頻率中斷的方式有關。本機使用者可利用此缺陷來耗盡資源，進而導致拒絕服務。(CVE-2021-28711)

    在 Linux 核心的 Xen hypervisor 子系統中，發現虛擬機器客體存在拒絕服務缺陷，此缺陷與使用者從其中一個客體呼叫某些高頻率中斷的方式有關。本機使用者可利用此缺陷來耗盡資源，進而導致拒絕服務。(CVE-2021-28712)

    在 Linux 核心的 Xen hypervisor 子系統中，發現虛擬機器客體存在拒絕服務缺陷，此缺陷與使用者從其中一個客體呼叫某些高頻率中斷的方式有關。本機使用者可利用此缺陷來耗盡資源，進而導致拒絕服務。(CVE-2021-28713)

    系統會緩衝 Linux 核心 netback 驅動程式中客體的傳入資料封包，直到客體準備好處理這些封包。目前已採取一些措施來防止資料過度堆積，但客體可以繞過這些措施：如果客體設法使其 RX 佇列響鈴頁面只需要一個可用插槽，而下一個套件需要多個可用插槽，甚至可能永遠不會觸發逾時 (這可能適用於使用 GSO、XDP 或軟體散雜湊的情況)。(CVE-2021-28714)

    系統會緩衝 Linux 核心 netback 驅動程式中客體的傳入資料封包，直到客體準備好處理這些封包。已經採取一些措施來避免堆積太多資料，但訪客可以繞過這些措施：介面的用戶端在停止使用新封包之前會經歷一次逾時，而且此逾時時間相當長 (預設為 60 秒)。
    在快速介面上使用 UDP 連線可輕易累積數 GB 的資料。
    (CVE-2021-28715)

    在 Linux 核心的 RDMA over Infiniband 實作中發現一個缺陷。具有特權的本機帳戶的攻擊者可在向 /dev/infiniband/rdma_cm 裝置節點發出命令時洩漏核心堆疊資訊。雖然此存取行為不太可能洩漏敏感的使用者資訊，但仍可進一步用來破解現有的核心保護機制。(CVE-2021-3923)

    在 Linux 核心適用於模擬網路裝置驅動程式的 eBPF 中發現記憶體流失缺陷，此缺陷與使用者針對裝置使用 BPF 的方式有關，例如呼叫 nsim_map_alloc_elem 函式。透過利用此缺陷，本機使用者未經授權即可存取某些資料。(CVE-2021-4135)

    在 XFS 檔案系統中 XFS_IOC_ALLOCSP IOCTL 允許未對齊大小的檔案增加大小的方式中發現資料洩漏缺陷。本機攻擊者可利用此缺陷洩漏 XFS 檔案系統上其以其他方式無法存取的資料。(CVE-2021-4155)

    在 Linux 核心的 Aquantia AQtion 乙太網路卡 Atlantic 驅動程式中發現超出邊界寫入缺陷，此缺陷與乙太網路卡提供惡意輸入給驅動程式的方式有關。本機使用者可利用此缺陷來模擬網路裝置並造成系統當機。此弱點對於機密性、完整性以及系統可用性的威脅最大。(CVE-2021-43975)

    在 Linux 核心中，下列弱點已解決：

    sctp：使用 call_rcu 釋放端點 (CVE-2021-46929)

    在 Linux 核心中，下列弱點已解決：

    i2c：驗證相容 ioctl 中的使用者資料

    錯誤的使用者資料可導致 i2c_transfer() 中發生警告，例如 zero msgs。使用者空間應無法觸發警告，因此此修補程式新增了針對 compact ioctl 中使用者資料的驗證檢查，以防止報告警告 (CVE-2021-46934)

    在 Linux 核心中，下列弱點已解決：

    net：修復 tw_timer_handler 中的釋放後使用問題 (CVE-2021-46936)

    在 Linux 核心的 Filesystem Context 功能中發現堆積型緩衝區溢位缺陷，此缺陷與 legacy_parse_param 函式驗證所提供的參數長度的方式有關。無特權的 (在啟用無特權使用者命名空間的情況下，否則需要有命名空間的 CAP_SYS_ADMIN 特權) 本機使用者若能開啟不支援 Filesystem Context API (因而遞補至舊版處理進程) 的檔案系統，便可利用此缺陷提升其在系統中的權限。(CVE-2022-0185)

    在核心基礎驅動程式的多種方法中，可能會發生因堆積緩衝區溢位而導致的超出邊界寫入。這可能會導致需要系統執行權限的本機權限提升。惡意利用弱點不需要使用者互動。產品：AndroidVersions：Android kernelAndroid ID：
    A-182388481 參照：上游核心 (CVE-2022-20166)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

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

  - 惡意後端可透過高頻率事件造成來賓拒絕服務 [其 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 驅動程式佔用大量核心記憶體 [其 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)

  - 在 Linux 核心適用於模擬網路裝置驅動程式的 eBPF 中，發現使用者針對裝置使用 BPF 的方式中存在記憶體流失弱點，可導致系統呼叫 nsim_map_alloc_elem 函式。透過利用此缺陷，本機使用者未經授權即可存取某些資料。(CVE-2021-4135)

  - 在 XFS 檔案系統中 XFS_IOC_ALLOCSP IOCTL 允許未對齊大小的檔案增加大小的方式中發現資料洩漏缺陷。本機攻擊者可利用此缺陷洩漏 XFS 檔案系統上其以其他方式無法存取的資料。(CVE-2021-4155)

  - 在 Linux 核心 5.15.2 及更早版本中，drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c 中的 hw_atl_utils_fw_rpc_wait 允許攻擊者（可以引入建構的裝置）透過建構的長度值觸發越界寫入弱點。(CVE-2021-43975)

  - 在 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 [內嵌] __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 [內嵌] 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 [內嵌] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [內嵌] 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 釋放，ep 做為 sk 的持有者，在呼叫 lock_sock() 時應該是作用中的。此修補程式使用 call_rcu()，並將 sock_put 和 ep free 移至 sctp_endpoint_destroy_rcu()，因此，嘗試在 sctp_transport_traverse_process() 中將 ep 保留在 rcu_read_lock 之下是安全的。如果 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 之前也不會發生任何剝離。請注意，延遲端點釋放不會延遲連接埠釋放，因為連接埠釋放會在呼叫 call_rcu() 之前的 sctp_endpoint_destroy() 中發生。此外，藉由 call_rcu() 釋放端點，可安全存取 sctp_assocs_seq_show() 和 sctp_rcv() 中 asoc->base.sk 的 sk。
    感謝 Jones 提出此問題。 v1->v2： - 改善變更記錄。 - 如 Jakub 所發現，將 kfree(ep) 新增至 sctp_endpoint_destroy_rcu()。 (CVE-2021-46929)

  - 在 Linux 核心中，下列弱點已解決：net/mlx5e：包覆 tx 報告者轉儲存回呼以擷取 sq 函式 mlx5e_tx_reporter_dump_sq() 將其 void * 引數轉換為結構 mlx5e_txqsq *，但在 TX-timeout-recovery 流程中引數實際的類型是結構 mlx5e_tx_timeout_ctx*. mlx5_core 0000:08:00.1 enp8s0f1：偵測到 TX 逾時 mlx5_core 0000:08:00.1 enp8s0f1: TX 佇列逾時：1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1，自上次傳輸以來 usecs: 21565000 BUG：在 0000000093f1a2de 命中堆疊保護頁面 (堆疊為 00000000b66ea0dc..000000004d932dae) 核心堆疊溢位 (頁面錯誤)：0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 硬體名稱：QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 工作佇列：mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core]  呼叫追踪：
    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 核心錯誤 - 未同步：嚴重例外狀況 核心位移：已停用 end 核心錯誤 - 未同步：嚴重例外狀況 若要修正此錯誤，在 mlx5e_tx_reporter_dump_sq() 中加入包裝函式，此包裝函式可從結構 mlx5e_tx_timeout_ctx 擷取 sq 並將其設定為 TX-timeout-recovery 流量轉儲存回呼。
    (CVE-2021-46931)

  - 在 Linux 核心中，下列弱點已解決：i2c：驗證相容 ioctl 中的使用者資料錯誤的使用者資料可能會在 i2c_transfer() 中造成警告，例如：零訊息。使用者空間應無法觸發警告，因此此修補程式新增 compact ioctl 中使用者資料的驗證檢查，以防止報告警告 (CVE-2021-46934)

  - 在 Linux 核心中，已解決下列弱點：net：修正 tw_timer_handler 中的釋放後使用弱點。在 Linux 5.4 中發現如下實際錯誤問題。錯誤： 無法處理以下位址的頁面錯誤：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_exit_batch 之前呼叫 ipv4_mib_exit_net，原因是 tcp_sk_ops 在 ipv4_mib_ops 之前註冊，這表示在 pernet_list 清單中，tcp_sk_ops 位於 ipv4_mib_ops 的前面。如果有某些傳送時間等待計時器，則 tw_timer_handler 中的 net->mib.net_statistics 會在 ipv4_mib_exit_net 之後發生釋放後使用。此錯誤並非在認可 f2bf415cfed7 (mib：新增 net 至 NET_ADD_STATS_BH) 中引入，因為 net_statistics 是全域變數，而非動態配置和釋放。實際上，是認可 61a7e26028b9 (mib：在結構網路上放置網路統計資料) 引入了此錯誤，因為它會在網路結構上放置網路統計資料，並在網路命名空間遭到損毀時予以釋放。將 init_ipv4_mibs() 移至 tcp_init() 的前端，即可修正此錯誤，同時以 panic() 取代 pr_crit()，因為在 init_ipv4_mibs() 失敗時繼續沒有意義。 [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 (CVE-2021-46936)

  - 在 Linux 核心的檔案系統內容功能的 legacy_parse_param 函式驗證所提供參數長度的方式中，發現一個堆積型緩衝區溢位缺陷。無特權的 (在啟用無特權使用者命名空間的情況下，否則需要有命名空間的 CAP_SYS_ADMIN 特權) 本機使用者若能開啟不支援 Filesystem Context API (因而遞補至舊版處理進程) 的檔案系統，便可利用此缺陷提升其在系統中的權限。(CVE-2022-0185)

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

遠端主機上安裝的核心版本早於 4.14.262-200.489。因此，會受到 ALAS2-2022-1749 公告中所提及的多個弱點影響。

  - 惡意後端可透過高頻率事件造成來賓拒絕服務 [其 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 驅動程式佔用大量核心記憶體 [其 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)

  - 在 Linux 核心的 Unix 網域通訊端檔案處置程式中，於使用者同時呼叫 close() 和 fget() 的方式中發現一個可能觸發爭用情形的釋放後記憶體缺陷。本機使用者可利用此缺陷造成系統當機，或提升自己的系統權限。
    此缺陷會影響 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 [內嵌] __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 [內嵌] 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 [內嵌] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [內嵌] 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 釋放，ep 做為 sk 的持有者，在呼叫 lock_sock() 時應該是作用中的。此修補程式使用 call_rcu()，並將 sock_put 和 ep free 移至 sctp_endpoint_destroy_rcu()，因此，嘗試在 sctp_transport_traverse_process() 中將 ep 保留在 rcu_read_lock 之下是安全的。如果 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 之前也不會發生任何剝離。請注意，延遲端點釋放不會延遲連接埠釋放，因為連接埠釋放會在呼叫 call_rcu() 之前的 sctp_endpoint_destroy() 中發生。此外，藉由 call_rcu() 釋放端點，可安全存取 sctp_assocs_seq_show() 和 sctp_rcv() 中 asoc->base.sk 的 sk。
    感謝 Jones 提出此問題。 v1->v2： - 改善變更記錄。 - 如 Jakub 所發現，將 kfree(ep) 新增至 sctp_endpoint_destroy_rcu()。 (CVE-2021-46929)

  - 在 Linux 核心中，已解決下列弱點：net：修正 tw_timer_handler 中的釋放後使用弱點。在 Linux 5.4 中發現如下實際錯誤問題。錯誤： 無法處理以下位址的頁面錯誤：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_exit_batch 之前呼叫 ipv4_mib_exit_net，原因是 tcp_sk_ops 在 ipv4_mib_ops 之前註冊，這表示在 pernet_list 清單中，tcp_sk_ops 位於 ipv4_mib_ops 的前面。如果有某些傳送時間等待計時器，則 tw_timer_handler 中的 net->mib.net_statistics 會在 ipv4_mib_exit_net 之後發生釋放後使用。此錯誤並非在認可 f2bf415cfed7 (mib：新增 net 至 NET_ADD_STATS_BH) 中引入，因為 net_statistics 是全域變數，而非動態配置和釋放。實際上，是認可 61a7e26028b9 (mib：在結構網路上放置網路統計資料) 引入了此錯誤，因為它會在網路結構上放置網路統計資料，並在網路命名空間遭到損毀時予以釋放。將 init_ipv4_mibs() 移至 tcp_init() 的前端，即可修正此錯誤，同時以 panic() 取代 pr_crit()，因為在 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
160423	Amazon Linux 2：kernel (ALASKERNEL-5.4-2022-021)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2024/5/27	high
160451	Amazon Linux 2：kernel (ALASKERNEL-5.10-2022-009)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2024/4/26	high
157408	Amazon Linux 2：核心 (ALAS-2022-1749)	Nessus	Amazon Linux Local Security Checks	2022/2/7	2024/4/25	high

偵測

搜尋 Plugin

high

high

high