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

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

    i2c：修正潛在的釋放後使用

    僅在我們使用完 adap 結構之後才將其釋放。此修補程式只是將 put_device() 向下移動一點，以免出現釋放後使用問題。

    [wsa：已新增程式碼註解，已新增修正標籤] (CVE-2019-25162)

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

    tun：避免 tun_free_netdev 中的重複釋放 (CVE-2021-47082)

    在 Linux 核心的 Atheros 無線介面卡驅動程式中，發現使用者強制 ath9k_htc_wait_for_target 函式失敗並顯示部分輸入訊息的方式中包含釋放後使用缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-1679)

    嘗試設定 SynIC IRQ 時，在 Linux 核心的 KVM 中發現一個缺陷。此問題可讓行為不當的 VMM 寫入 SYNIC/STIMER MSR，進而造成 NULL 指標解除參照。此缺陷允許主機上無權限的本機攻擊者發出特定的 ioctl 呼叫，進而造成可導致拒絕服務的核心 oops 情形。(CVE-2022-2153)

    在 Linux 核心的 POSIX CPU 計時器功能中發現釋放後使用缺陷，其中使用者先建立計時器，然後在程式的非 leader 執行緒中將之刪除。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-2585)

    據發現，nft 物件或運算式可參照不同 nft 表格上的 nft 集，進而導致在刪除該表格時發生釋放後使用。(CVE-2022-2586)

    在 Linux 核心中，發現 net/sched/cls_route.c 篩選器實作中的 route4_change 存在釋放後使用瑕疵。這使本機使用者可以造成系統當機，且可能導致本機特權提升問題。(CVE-2022-2588)

    某些 Intel(R) 處理器在內容之間不透明地共用回傳預測器目標，這讓授權使用者可以透過本機存取權造成資訊洩漏。(CVE-2022-26373)

    在 Linux 核心的 nf_conntrack_irc 中發現一個問題，其中的訊息處理可能會發生混淆並且與訊息錯誤對應。當使用者在已設定 nf_conntrack_irc 的情況下使用未加密的 IRC 時，可能能夠繞過防火牆。(CVE-2022-2663)

    在 Linux 核心的 BPF 子系統中，使用者以大於對應 max_entries 的金鑰呼叫 bpf_tail_call 函式的方式中存在超出邊界讀取記憶體的缺陷。本機使用者利用此缺陷，未經授權即可存取某些資料。(CVE-2022-2905)

    當同時發生多個對 xfrm_probe_algs 的呼叫時，Linux 核心中用於轉換封包的 IP 架構 (XFRM 子系統) 存在爭用情形。此缺陷讓本機攻擊者可能透過執行超出邊界讀取並將其複製到通訊端，來觸發超出邊界寫入或洩漏核心堆積記憶體。(CVE-2022-3028)

    在 Linux 核心的 io_uring 中發現釋放後使用缺陷。如果使用 io_uring 輪詢輪詢 signalfd 或 binder fd，因為缺少 io_uring POLLFREE 處理，此瑕疵允許本機使用者觸發此問題。(CVE-2022-3176)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「嚴重」。這會影響 IPsec 元件中 net/core/devlink.c 檔案的 devlink_param_set/devlink_param_get 函式。操控此弱點可導致釋放後使用。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211929。(CVE-2022-3625)

    在 5.19 版之前的 Linux 核心中，發現 include/asm-generic/tlb.h 中存在問題。由於存在爭用情形 (unmap_mapping_range 與 munmap)，裝置驅動程式可在頁面仍具有過時 TLB 項目時釋放此頁面。只有在使用 VM_PFNMAP VMA 的情況下，才會發生此問題。(CVE-2022-39188)

    在 Linux 核心 5.19.6 之前版本的 net/netfilter/nf_tables_api.c 中發現一個問題。繫結至已繫結的鏈結時，可能會發生拒絕服務。(CVE-2022-39190)

    在 Linux 核心的 EFI Capsule 載入器驅動程式中，發現程式在 EFI Capsule 裝置節點上處理寫入和排清作業的方式存在爭用條件。本機使用者可利用此缺陷造成系統當機或存在此可能 (CVE-2022-40307)

    在 Linux 核心 5.13.3 之前版本的 mm/mremap.c 中，因為在 PUD 移動期間未保留 rmap 鎖定，所以可透過過時 TLB 觸發釋放後使用問題。(CVE-2022-41222)

    在 Linux 核心的 TUN/TAP 裝置驅動程式功能中，當 register_netdevice 函式 (NETDEV_REGISTER 通知程式) 失敗時，在使用者登記裝置的方式中發現重複釋放瑕疵。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-4744)

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

    IB/核心：修正 ODP 流程期間巢狀鎖死情形 (CVE-2022-48675)

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

    nvme-tcp：修正偵測到雜湊錯誤時發生釋放後使用的問題 (CVE-2022-48686)

    在 Linux 核心中，下列弱點已解決：ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. (CVE-2022-48687)

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

    i40e：修正模組移除期間核心當機的問題 (CVE-2022-48688)

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

    netfilter：nf_tables：卸載標記檢查失敗時移除勾點清單 (CVE-2022-48691)

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

    scsi：mpt3sas：修復釋放後使用警告 (CVE-2022-48695)

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

    nvmet：修正釋放後使用錯誤 (CVE-2022-48697)

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

    drm/radeon：新增強制排清以在 radeon 時延遲工作 (CVE-2022-48704)

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

    sched/fair修正 reweight_entity 中的錯誤 (CVE-2022-48921)

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

    tcp：修正有關 sysctl_tcp_l3mdev_accept 的資料爭用。(CVE-2022-49599)

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

    USB：core：防止巢狀裝置重設呼叫 (CVE-2022-49936)

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

    vt：變更字型前清除選取項目 (CVE-2022-49948)

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

    net/sched修正 attach_default_qdiscs() 中的 netdevice 參照洩漏 (CVE-2022-49958)

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

    arm64cacheinfo修正將已簽署錯誤值不正確指派給未簽署 fw_level 的問題 (CVE-2022-49964)

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

    bpf不要以無效的 pkt_len 重新導向封包 (CVE-2022-49975)

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

    ftrace：修正 ftrace 無作用時 is_ftrace_trampoline 中的 NULL 指標解除參照 (CVE-2022-49977)

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

    net修正 sk_psock_get 中的參照計數錯誤 (2) (CVE-2022-49979)

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

    HID：hidraw：修正 hidraw_release() 中的記憶體洩漏 (CVE-2022-49981)

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

    HIDsteam防止在 Steam_{recv,send}_report 中發生 NULL 指標解除參照 (CVE-2022-49984)

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

    bpf不對戳描述符號的陣列範圍檢查使用 tnum_range (CVE-2022-49985)

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

    scsistorvsc從 storvsc_error_wq 移除 WQ_MEM_RECLAIM (CVE-2022-49986)

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

    md：呼叫 md_stop 中的 __md_stop_writes (CVE-2022-49987)

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

    xen/privcmd修正 privcmd_ioctl_dm_op() 的錯誤結束 (CVE-2022-49989)

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

    迴圈：設定迴圈時檢查溢位 (CVE-2022-49993)

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

    rxrpc修正 rxrpc 之 sendmsg 中的鎖定 (CVE-2022-49998)

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

    xfrmpolicy修正詮釋資料 dst->dev xmit null 指標解除參照 (CVE-2022-50004)

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

    NFSv4.2 修正 __nfs42_ssc_open 的問題 (CVE-2022-50006)

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

    xfrm修正 __xfrm_policy_check() 中的 refcount 洩漏 (CVE-2022-50007)

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

    kprobes：不針對已停用的 kprobe 呼叫 disarm_kprobe() (CVE-2022-50008)

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

    drivers：md：修正潛在的釋放後使用錯誤 (CVE-2022-50022)

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

    scsilpfc防止緩衝區溢位在具有格式錯誤使用者輸入的 debugfs 中損毀 (CVE-2022-50030)

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

    netgenl修正原則轉儲存中的錯誤路徑記憶體洩漏 (CVE-2022-50042)

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

    iavf修正 adminq 錯誤處理 (CVE-2022-50055)

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

    ceph不洩漏 handle_cap_grant 中的 snap_rwsem (CVE-2022-50059)

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

    virtio_net修正可合併的 XPD_TX 內的記憶體洩漏 (CVE-2022-50065)

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

    NFSv4/pnfs修正開啟中的釋放後使用錯誤 (CVE-2022-50072)

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

    ext4修正 ext4_iomap_begin 中關於 bmap 和 write 爭用的警告 (CVE-2022-50082)

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

    ext4：在 xattr.h 中新增 EXT4_INODE_HAS_XATTR_SPACE 巨集 (CVE-2022-50083)

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

    dm raid：修正 raid_status 中的位址清理程式警告 (CVE-2022-50084)

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

    dm raid：修正 raid_resume 中的位址清理程式警告 (CVE-2022-50085)

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

    firmwarearm_scpi確保探查失敗時未指派 scpi_info (CVE-2022-50087)

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

    dm Thin：修正 dm_sm_register_threshold_callback 中的釋放後使用損毀 (CVE-2022-50092)

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

    iommu/vt-d避免透過 node_online(NUMA_NO_NODE) 的無效記憶體存取 (CVE-2022-50093)

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

    posix-cpu-timers在執行期間清除 CPU 計時器之前將其釋放 (CVE-2022-50095)

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

    video：fbdev：s3fb：使用 memset_io() 前檢查螢幕尺寸 (CVE-2022-50097)

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

    sched、cpuset修正因清空 cs->cpus_allowed 導致的 dl_cpu_busy() 不穩定 (CVE-2022-50103)

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

    jbd2：修正日誌中止時的宣告 'jh->b_frozen_data == NULL' 失敗 (CVE-2022-50126)

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

    RDMA/rxe：修正 rxe_create_qp() 中的錯誤解開 (CVE-2022-50127)

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

    RDMA/srpt修正釋放後使用 (CVE-2022-50129)

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

    RDMA/qedr修正 __qedr_alloc_mr() 中的潛在記憶體洩漏 (CVE-2022-50138)

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

    驅動程式核心修正 __driver_attach 中的潛在鎖死 (CVE-2022-50149)

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

    usb：host：修正 ehci_hcd_ppc_of_probe 中的 refcount 洩漏 (CVE-2022-50153)

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

    virtio-gpu修正遺漏的檢查以避免 NULL 解除參照 (CVE-2022-50181)

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

    drm/radeon：修正 ni_set_mc_special_registers() 中的潛在緩衝區溢位 (CVE-2022-50185)

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

    ulator: of修正 of_get_section_constraints() 中的 refcount 洩漏錯誤 (CVE-2022-50191)

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

    selinux：在 put_entry() 中新增邊界檢查 (CVE-2022-50200)

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

    PM：hibernate：從休眠狀態恢復時延遲裝置探查 (CVE-2022-50202)

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

    ext2：新增更多的 inode 計數有效性檢查 (CVE-2022-50205)

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

    arm64：修正並行設定 insn_emulation sysctls 中的 oops (CVE-2022-50206)

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

    md-raid10：修正 KASAN 警告 (CVE-2022-50211)

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

    netfilternf_tables不允許 CHAIN_ID 參照其他表格 (CVE-2022-50212)

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

    netfilter：nf_tables：不允許 SET_ID 參照其他表格 (CVE-2022-50213)

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

    scsi：sg：允許在移除的裝置上等待命令完成 (CVE-2022-50215)

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

    bpf修正 compute_effect_progs 中的 KASAN 釋放後使用讀取 (CVE-2022-50219)

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

    usbnet：修正中斷連線時的 linkwatch 釋放後使用 (CVE-2022-50220)

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

    ttyvt初始化 unicode 畫面緩衝區 (CVE-2022-50222)

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

    KVM：SVM：如果使用者空間插入具有 GIF=0 的中斷，則不要 BUG (CVE-2022-50228)

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

    cryptoarm64/poly1305 - 修正讀取超出邊界問題 (CVE-2022-50231)

    在 nf_tables_updtable 中，如果 nf_tables_table_enable 傳回錯誤，程式會呼叫 nft_trans_destroy 以釋放交易物件。nft_trans_destroy() 會呼叫 list_del()，但從未將交易放置在清單上
    -- 清單標頭全部為零，這會導致 NULL 指標解除參照。(CVE-2023-1095)

    上游公告對此問題的描述如下：

    本機攻擊者可以利用此弱點，在安裝 Linux 核心的受影響裝置上造成敏感資訊洩漏。攻擊者必須先取得在目標系統上執行高特權程式碼的能力，才能攻擊此弱點。

    此特定弱點存在於 seg6 屬性的處理中。這是未正確驗證使用者提供的資料所導致，攻擊者可利用此缺陷造成讀取範圍超過所分配的緩衝區末尾。
    攻擊者可結合其他弱點，在核心的環境中提升權限並執行任意程式碼。(CVE-2023-2860)

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

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

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

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

    i2c：修正潛在的釋放後使用

    僅在我們使用完 adap 結構之後才將其釋放。此修補程式只是將 put_device() 向下移動一點，以免出現釋放後使用問題。

    [wsa：已新增程式碼註解，已新增修正標籤] (CVE-2019-25162)

    處理內部資料結構時，在 Linux 核心的 EBPF 驗證程式中發現一個弱點。
    內部記憶體位置可傳回使用者空間。有權將 eBPF 程式碼插入核心的本機攻擊者可利用此弱點洩露內部核心記憶體詳細資料，使目前針對核心的一些弱點緩解措施變得無效。(CVE-2021-4159)

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

    thermal：修正 of_thermal_ 函式中的 NULL 指標解除參照問題 (CVE-2021-47202)

    在 Linux 核心的 Atheros 無線介面卡驅動程式中，發現使用者強制 ath9k_htc_wait_for_target 函式失敗並顯示部分輸入訊息的方式中包含釋放後使用缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-1679)

    在 v4l2-mem2mem.c 的 v4l2_m2m_querybuf 中，由於輸入驗證不當，可能發生超出邊界寫入。這可能會導致需要系統執行權限的本機特權提升。惡意利用弱點不需要使用者互動。產品：AndroidVersions：Android kernelAndroid ID：
    A-223375145References：上游核心 (CVE-2022-20369)

    嘗試設定 SynIC IRQ 時，在 Linux 核心的 KVM 中發現一個缺陷。此問題可讓行為不當的 VMM 寫入 SYNIC/STIMER MSR，進而造成 NULL 指標解除參照。此缺陷允許主機上無權限的本機攻擊者發出特定的 ioctl 呼叫，進而造成可導致拒絕服務的核心 oops 情形。(CVE-2022-2153)

    據發現，nft 物件或運算式可參照不同 nft 表格上的 nft 集，進而導致在刪除該表格時發生釋放後使用。(CVE-2022-2586)

    在 Linux 核心中，發現 net/sched/cls_route.c 篩選器實作中的 route4_change 存在釋放後使用瑕疵。這使本機使用者可以造成系統當機，且可能導致本機特權提升問題。(CVE-2022-2588)

    某些 Intel(R) 處理器在內容之間不透明地共用回傳預測器目標，這讓授權使用者可以透過本機存取權造成資訊洩漏。(CVE-2022-26373)

    在 Linux 核心的 nf_conntrack_irc 中發現一個問題，其中的訊息處理可能會發生混淆並且與訊息錯誤對應。當使用者在已設定 nf_conntrack_irc 的情況下使用未加密的 IRC 時，可能能夠繞過防火牆。(CVE-2022-2663)

    當同時發生多個對 xfrm_probe_algs 的呼叫時，Linux 核心中用於轉換封包的 IP 架構 (XFRM 子系統) 存在爭用情形。此缺陷讓本機攻擊者可能透過執行超出邊界讀取並將其複製到通訊端，來觸發超出邊界寫入或洩漏核心堆積記憶體。(CVE-2022-3028)

    在 Linux 核心的 io_uring 中發現釋放後使用缺陷。如果使用 io_uring 輪詢輪詢 signalfd 或 binder fd，因為缺少 io_uring POLLFREE 處理，此瑕疵允許本機使用者觸發此問題。(CVE-2022-3176)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「嚴重」。這會影響 IPsec 元件中 net/core/devlink.c 檔案的 devlink_param_set/devlink_param_get 函式。操控此弱點可導致釋放後使用。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211929。(CVE-2022-3625)

    在 5.19 版之前的 Linux 核心中，發現 include/asm-generic/tlb.h 中存在問題。由於存在爭用情形 (unmap_mapping_range 與 munmap)，裝置驅動程式可在頁面仍具有過時 TLB 項目時釋放此頁面。只有在使用 VM_PFNMAP VMA 的情況下，才會發生此問題。(CVE-2022-39188)

    在 Linux 核心的 EFI Capsule 載入器驅動程式中，發現程式在 EFI Capsule 裝置節點上處理寫入和排清作業的方式存在爭用條件。本機使用者可利用此缺陷造成系統當機或存在此可能 (CVE-2022-40307)

    在 Linux 核心 5.13.3 之前版本的 mm/mremap.c 中，因為在 PUD 移動期間未保留 rmap 鎖定，所以可透過過時 TLB 觸發釋放後使用問題。(CVE-2022-41222)

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

    nvme-tcp：修正偵測到雜湊錯誤時發生釋放後使用的問題 (CVE-2022-48686)

    在 Linux 核心中，下列弱點已解決：ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. (CVE-2022-48687)

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

    i40e：修正模組移除期間核心當機的問題 (CVE-2022-48688)

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

    scsi：mpt3sas：修復釋放後使用警告 (CVE-2022-48695)

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

    nvmet：修正釋放後使用錯誤 (CVE-2022-48697)

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

    drm/radeon：新增強制排清以在 radeon 時延遲工作 (CVE-2022-48704)

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

    KVM不要使 ops->destroy 解除參照 (CVE-2022-49568)

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

    USBcore防止巢狀裝置重設呼叫 (CVE-2022-49936)

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

    vt變更字型前清除選取項目 (CVE-2022-49948)

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

    arm64cacheinfo修正將已簽署錯誤值不正確指派給未簽署 fw_level 的問題 (CVE-2022-49964)

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

    ftrace：修正 ftrace 無作用時 is_ftrace_trampoline 中的 NULL 指標解除參照 (CVE-2022-49977)

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

    HIDhidraw修正 hidraw_release() 中的記憶體洩漏 (CVE-2022-49981)

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

    HIDsteam防止在 Steam_{recv,send}_report 中發生 NULL 指標解除參照 (CVE-2022-49984)

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

    scsistorvsc從 storvsc_error_wq 移除 WQ_MEM_RECLAIM (CVE-2022-49986)

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

    md：呼叫 md_stop 中的 __md_stop_writes (CVE-2022-49987)

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

    kprobes：不針對已停用的 kprobe 呼叫 disarm_kprobe() (CVE-2022-50008)

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

    ext4避免調整為部分叢集大小 (CVE-2022-50020)

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

    driversmd修正潛在的釋放後使用錯誤 (CVE-2022-50022)

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

    scsilpfc防止緩衝區溢位在具有格式錯誤使用者輸入的 debugfs 中損毀 (CVE-2022-50030)

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

    iavf修正 adminq 錯誤處理 (CVE-2022-50055)

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

    NFSv4/pnfs修正開啟中的釋放後使用錯誤 (CVE-2022-50072)

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

    ext4：在 xattr.h 中新增 EXT4_INODE_HAS_XATTR_SPACE 巨集 (CVE-2022-50083)

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

    dm raid修正 raid_status 中的位址清理程式警告 (CVE-2022-50084)

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

    dm raid修正 raid_resume 中的位址清理程式警告 (CVE-2022-50085)

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

    firmwarearm_scpi確保探查失敗時未指派 scpi_info (CVE-2022-50087)

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

    dm Thin修正 dm_sm_register_threshold_callback 中的釋放後使用損毀 (CVE-2022-50092)

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

    video：fbdev：s3fb：使用 memset_io() 前檢查螢幕尺寸 (CVE-2022-50097)

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

    視訊fbdevamba-clcd修正 refcount 洩漏錯誤 (CVE-2022-50109)

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

    jbd2：修正日誌中止時的宣告 'jh->b_frozen_data == NULL' 失敗 (CVE-2022-50126)

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

    RDMA/rxe：修正 rxe_create_qp() 中的錯誤解開 (CVE-2022-50127)

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

    驅動程式核心修正 __driver_attach 中的潛在鎖死 (CVE-2022-50149)

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

    usbhost修正 ehci_hcd_ppc_of_probe 中的 refcount 洩漏 (CVE-2022-50153)

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

    drm/radeon：修正 ni_set_mc_special_registers() 中的潛在緩衝區溢位 (CVE-2022-50185)

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

    ulator: of修正 of_get_section_constraints() 中的 refcount 洩漏錯誤 (CVE-2022-50191)

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

    selinux：在 put_entry() 中新增邊界檢查 (CVE-2022-50200)

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

    PM：hibernate：從休眠狀態恢復時延遲裝置探查 (CVE-2022-50202)

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

    ext2：新增更多的 inode 計數有效性檢查 (CVE-2022-50205)

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

    arm64修正並行設定 insn_emulation sysctls 中的 oops (CVE-2022-50206)

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

    md-raid10：修正 KASAN 警告 (CVE-2022-50211)

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

    scsisg允許在移除的裝置上等待命令完成 (CVE-2022-50215)

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

    usbnet：修正中斷連線時的 linkwatch 釋放後使用 (CVE-2022-50220)

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

    ttyvt初始化 unicode 畫面緩衝區 (CVE-2022-50222)

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

    KVM：SVM：如果使用者空間插入具有 GIF=0 的中斷，則不要 BUG (CVE-2022-50228)

    在 nf_tables_updtable 中，如果 nf_tables_table_enable 傳回錯誤，程式會呼叫 nft_trans_destroy 以釋放交易物件。nft_trans_destroy() 會呼叫 list_del()，但從未將交易放置在清單上
    -- 清單標頭全部為零，這會導致 NULL 指標解除參照。(CVE-2023-1095)

    上游公告對此問題的描述如下：

    本機攻擊者可以利用此弱點，在安裝 Linux 核心的受影響裝置上造成敏感資訊洩漏。攻擊者必須先取得在目標系統上執行高特權程式碼的能力，才能攻擊此弱點。

    此特定弱點存在於 seg6 屬性的處理中。這是未正確驗證使用者提供的資料所導致，攻擊者可利用此缺陷造成讀取範圍超過所分配的緩衝區末尾。
    攻擊者可結合其他弱點，在核心的環境中提升權限並執行任意程式碼。(CVE-2023-2860)

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

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

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1780562693 公告中提及的多個弱點影響。

  - 在 5.16.12 之前的 Linux 核心中發現一個問題。drivers/net/usb/sr9700.c 允許攻擊者透過裝置的特製框架長度，從堆積記憶體取得敏感資訊。(CVE-2022-26966)

  - 已解決 Linux 核心中的下列弱點：kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r
    __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table.
    Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
    aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list :
    show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop :
    warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at
    __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130
    __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm:
    execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP:
    0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
    0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

  - 已解決 Linux 核心中的下列弱點：tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write. [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28;
    int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51;
    int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63 >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \ events/sched/sched_waking/trigger # echo hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid) >> events/sched/sched_switch/trigger [2] BUG: unable to handle page fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09:
    0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3:
    0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX:
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

  - 已解決 Linux 核心中的下列弱點：net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - 已解決 Linux 核心中的下列弱點：net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. (CVE-2024-38553)

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

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - kprobes不針對已停用的 kprobe 呼叫 disarm_kprobe()。__disable_kprobe() 中的假設有誤它可嘗試解除設防已解除設防的 kprobe並觸發以下 WARN_ONCE()。 [0] 我們可以輕鬆地重現此問題。 1. 將 0 寫入 /sys/kernel/debug/kprobes/enabled。 # echo 0 > /sys/kernel/debug/kprobes/enabled 2. 執行 execsnoop。目前已停用一個 kprobe。 # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [停用][ FTRACE] 3. 寫入 1 至 /sys/kernel/debug/kprobes/enabled其會將 kprobes_all_disarmed 變更為 false但不會布防已停用的 kprobe。 # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. 當 __disable_kprobe() 為已停用的 kprobe 呼叫 disarm_kprobe() 並命中 __disarm_kprobe_ftrace() 中的 WARN_ONCE() 時終止 execsnoop。 # fg /usr/share/bcc/tools/execsnoop ^C 實際上WARN_ONCE() 已觸發兩次且 __unregister_kprobe_top() 遺漏一些清理作業並將匯總 kprobe 保留在雜湊表中。接著__unregister_trace_kprobe() 會初始化 tk->rp.kp.list 並建立類似這樣的無限迴圈。匯總 kprobe.list -> kprobe.list
    -. ^ | 「.__.」在此情況下這些命令會陷入無限迴圈並導致 RCU 停止或軟鎖定。 cat /sys/kernel/debug/kprobes/listshow_kprobe_addr() 透過 RCU 進入無限迴圈。 /usr/share/bcc/tools/execsnoopwarn_kprobe_rereg() 保留 kprobe_mutex且 __get_valid_kprobe() 停滯在迴圈中。若要避免此問題請確認我們不會針對已停用的 kprobe 呼叫 disarm_kprobe()。 [0] 無法解除 __x64_sys_execve+0x0/0x40 的 kprobe-ftrace (錯誤 -2) 警告 kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) 的 CPU6 PID: 2460連結的模組ena CPU6 PID2460 通訊execsnoop 未受污染 5.19.0+ #28 硬體名稱Amazon EC2 c5.2xlarge/、BIOS 1.0 2017 年 10 月 16 日 RIP0010:__disarm_kprobe_ftrace.isra.19 (kernel /kprobes.c:1129) 程式碼24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS00010282 RAX
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
     R110000000000000000  : ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000600003:
    00000000fffe0ff0 DR70000000000000400 PKRU55555554 呼叫追踪 <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/disabletrace_kprobe.c:340/disabletrace_kprobe.c:340/disabletrace_kprobe.c:340/disabletrace_kprobe) trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events /core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

    使用者使用惡意資料觸發 ioctl FBIOPUT_VSCREENINFO 時，在 Linux 核心的框架緩衝區型主控台驅動程式功能中發現超出邊界寫入缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2021-33655)

    處理內部資料結構時，在 Linux 核心的 EBPF 驗證程式中發現一個弱點。
    內部記憶體位置可傳回使用者空間。有權將 eBPF 程式碼插入核心的本機攻擊者可利用此弱點洩露內部核心記憶體詳細資料，使目前針對核心的一些弱點緩解措施變得無效。(CVE-2021-4159)

    在 Linux 核心的 TeleTYpe 子系統中發現超出邊界讀取缺陷。由於 flush_to_ldisc 函式中存在記憶體洩漏弱點，使用者利用 ioctls 的 TIOCSPTLCK、TIOCGPTPEER、TIOCSTI 和 TCXONC 觸發爭用情形時會發生此問題。本機使用者可利用此缺陷造成系統當機，或從記憶體讀取未經授權的隨機資料。(CVE-2022-1462)

    在 Linux 核心的 Atheros 無線介面卡驅動程式中，發現使用者強制 ath9k_htc_wait_for_target 函式失敗並顯示部分輸入訊息的方式中包含釋放後使用缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-1679)

    嘗試設定 SynIC IRQ 時，在 Linux 核心的 KVM 中發現一個缺陷。此問題可讓行為不當的 VMM 寫入 SYNIC/STIMER MSR，進而造成 NULL 指標解除參照。此缺陷允許主機上無權限的本機攻擊者發出特定的 ioctl 呼叫，進而造成可導致拒絕服務的核心 oops 情形。(CVE-2022-2153)

    在 Linux 核心中，發現 net/sched/cls_route.c 篩選器實作中的 route4_change 存在釋放後使用瑕疵。這使本機使用者可以造成系統當機，且可能導致本機特權提升問題。(CVE-2022-2588)

    在 Linux 核心的 nf_conntrack_irc 中發現一個問題，其中的訊息處理可能會發生混淆並且與訊息錯誤對應。當使用者在已設定 nf_conntrack_irc 的情況下使用未加密的 IRC 時，可能能夠繞過防火牆。(CVE-2022-2663)

    當同時發生多個對 xfrm_probe_algs 的呼叫時，Linux 核心中用於轉換封包的 IP 架構 (XFRM 子系統) 存在爭用情形。此缺陷讓本機攻擊者可能透過執行超出邊界讀取並將其複製到通訊端，來觸發超出邊界寫入或洩漏核心堆積記憶體。(CVE-2022-3028)

    在 Linux 核心的網路程式碼中發現一個缺陷。將相同 SKB 排入佇列 (並釋放) 至子 qdisc 之後，在 sch_sfb enqueue 函式使用通訊端緩衝區 (SKB) cb 欄位的方式中發生釋放後使用弱點。無權限的本機使用者可利用此缺陷造成系統當機，進而引發拒絕服務。(CVE-2022-3586)

    在 Linux 核心中，發現適用於虛擬機器的 XEN Hypervisor 中存在記憶體存取缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。
    (CVE-2022-36123)

    在 Linux 核心 5.18.14 以及之前版本中發現一個問題。 net/xfrm/xfrm_policy.c 中的 xfrm_expand_policies 可造成一個參照計數被捨棄兩次。(CVE-2022-36879)

    在 Linux 核心的 Netfilter 子系統中，發現本機使用者在分析損毀的網路封包時使用 libnetfilter_queue 的方式中存在記憶體損毀缺陷。這使本機使用者可以造成系統當機，或使遠端使用者在本機使用者使用 libnetfilter_queue 時造成系統當機。
    (CVE-2022-36946)

    在 5.19 版之前的 Linux 核心中，發現 include/asm-generic/tlb.h 中存在問題。由於存在爭用情形 (unmap_mapping_range 與 munmap)，裝置驅動程式可在頁面仍具有過時 TLB 項目時釋放此頁面。只有在使用 VM_PFNMAP VMA 的情況下，才會發生此問題。(CVE-2022-39188)

    在 Linux 核心的 EFI Capsule 載入器驅動程式中，發現程式在 EFI Capsule 裝置節點上處理寫入和排清作業的方式存在爭用條件。本機使用者可利用此缺陷造成系統當機或存在此可能 (CVE-2022-40307)

    在 5.19.7 版之前的 Linux 核心中，mm/rmap.c 存在與分葉 anon_vma 雙重重複使用相關的釋放後使用問題。
    (CVE-2022-42703)

    在 Linux 核心中，下列弱點已解決：ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. (CVE-2022-48687)

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

    scsi：mpt3sas：修復釋放後使用警告 (CVE-2022-48695)

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

    drm/radeon：新增強制排清以在 radeon 時延遲工作 (CVE-2022-48704)

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

    USB：core：防止巢狀裝置重設呼叫 (CVE-2022-49936)

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

    vt：變更字型前清除選取項目 (CVE-2022-49948)

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

    ftrace：修正 ftrace 無作用時 is_ftrace_trampoline 中的 NULL 指標解除參照 (CVE-2022-49977)

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

    HID：hidraw：修正 hidraw_release() 中的記憶體洩漏 (CVE-2022-49981)

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

    md：呼叫 md_stop 中的 __md_stop_writes (CVE-2022-49987)

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

    迴圈：設定迴圈時檢查溢位 (CVE-2022-49993)

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

    xfrm修正 __xfrm_policy_check() 中的 refcount 洩漏 (CVE-2022-50007)

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

    kprobes：不針對已停用的 kprobe 呼叫 disarm_kprobe() (CVE-2022-50008)

    上游公告對此問題的描述如下：

    本機攻擊者可以利用此弱點，在安裝 Linux 核心的受影響裝置上造成敏感資訊洩漏。攻擊者必須先取得在目標系統上執行高特權程式碼的能力，才能攻擊此弱點。

    此特定弱點存在於 seg6 屬性的處理中。這是未正確驗證使用者提供的資料所導致，攻擊者可利用此缺陷造成讀取範圍超過所分配的緩衝區末尾。
    攻擊者可結合其他弱點，在核心的環境中提升權限並執行任意程式碼。(CVE-2023-2860)

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

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

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

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

    i2c：修正潛在的釋放後使用

    僅在我們使用完 adap 結構之後才將其釋放。此修補程式只是將 put_device() 向下移動一點，以免出現釋放後使用問題。

    [wsa：已新增程式碼註解，已新增修正標籤] (CVE-2019-25162)

    在 Linux 核心的 Atheros 無線介面卡驅動程式中，發現使用者強制 ath9k_htc_wait_for_target 函式失敗並顯示部分輸入訊息的方式中包含釋放後使用缺陷。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-1679)

    在 Linux 核心的 POSIX CPU 計時器功能中發現釋放後使用缺陷，其中使用者先建立計時器，然後在程式的非 leader 執行緒中將之刪除。本機使用者可利用此缺陷造成系統當機，或可能提升自己的系統權限。(CVE-2022-2585)

    據發現，nft 物件或運算式可參照不同 nft 表格上的 nft 集，進而導致在刪除該表格時發生釋放後使用。(CVE-2022-2586)

    在 Linux 核心中，發現 net/sched/cls_route.c 篩選器實作中的 route4_change 存在釋放後使用瑕疵。這使本機使用者可以造成系統當機，且可能導致本機特權提升問題。(CVE-2022-2588)

    某些 Intel(R) 處理器在內容之間不透明地共用回傳預測器目標，這讓授權使用者可以透過本機存取權造成資訊洩漏。(CVE-2022-26373)

    在 Linux 核心的 nf_conntrack_irc 中發現一個問題，其中的訊息處理可能會發生混淆並且與訊息錯誤對應。當使用者在已設定 nf_conntrack_irc 的情況下使用未加密的 IRC 時，可能能夠繞過防火牆。(CVE-2022-2663)

    在 Linux 核心的 BPF 子系統中，使用者以大於對應 max_entries 的金鑰呼叫 bpf_tail_call 函式的方式中存在超出邊界讀取記憶體的缺陷。本機使用者利用此缺陷，未經授權即可存取某些資料。(CVE-2022-2905)

    當同時發生多個對 xfrm_probe_algs 的呼叫時，Linux 核心中用於轉換封包的 IP 架構 (XFRM 子系統) 存在爭用情形。此缺陷讓本機攻擊者可能透過執行超出邊界讀取並將其複製到通訊端，來觸發超出邊界寫入或洩漏核心堆積記憶體。(CVE-2022-3028)

    在 Linux 核心的 io_uring 中發現釋放後使用缺陷。如果使用 io_uring 輪詢輪詢 signalfd 或 binder fd，因為缺少 io_uring POLLFREE 處理，此瑕疵允許本機使用者觸發此問題。(CVE-2022-3176)

    在 Linux 核心的音效子系統中發現因不當鎖定導致的爭用情形。處理 SNDCTL_DSP_SYNC ioctl 時，此缺陷可導致 NULL 指標解除參照。有權限的本機使用者 (根使用者或音訊群組的成員) 可利用此缺陷使系統當機，進而導致拒絕服務情形。(CVE-2022-3303)

    在 Linux 核心中發現一個弱點。目前已將其歸類為「嚴重」。這會影響 IPsec 元件中 net/core/devlink.c 檔案的 devlink_param_set/devlink_param_get 函式。操控此弱點可導致釋放後使用。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-211929。(CVE-2022-3625)

    在 5.19 版之前的 Linux 核心中，發現 include/asm-generic/tlb.h 中存在問題。由於存在爭用情形 (unmap_mapping_range 與 munmap)，裝置驅動程式可在頁面仍具有過時 TLB 項目時釋放此頁面。只有在使用 VM_PFNMAP VMA 的情況下，才會發生此問題。(CVE-2022-39188)

    在 Linux 核心的 x86 KVM 子系統中，發現 arch/x86/kvm/x86.c 中的 kvm_steal_time_set_preempted 存在瑕疵。無權限的來賓使用者可入侵來賓核心，這是因為在某些 KVM_VCPU_PREEMPTED 情況下，程式未正確處理 TLB 排清作業。(CVE-2022-39189)

    在 Linux 核心 5.19.6 之前版本的 net/netfilter/nf_tables_api.c 中發現一個問題。繫結至已繫結的鏈結時，可能會發生拒絕服務。(CVE-2022-39190)

    在 Linux 核心的 EFI Capsule 載入器驅動程式中，發現程式在 EFI Capsule 裝置節點上處理寫入和排清作業的方式存在爭用條件。本機使用者可利用此缺陷造成系統當機或存在此可能 (CVE-2022-40307)

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

    IB/核心：修正 ODP 流程期間巢狀鎖死情形 (CVE-2022-48675)

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

    nvme-tcp：修正偵測到雜湊錯誤時發生釋放後使用的問題 (CVE-2022-48686)

    在 Linux 核心中，下列弱點已解決：ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. (CVE-2022-48687)

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

    tcp：TX zerocopy 不應偵測 pfmemalloc 狀態 (CVE-2022-48689)

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

    netfilter：nf_tables：卸載標記檢查失敗時移除勾點清單 (CVE-2022-48691)

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

    scsi：mpt3sas：修復釋放後使用警告 (CVE-2022-48695)

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

    sched/debug：修正 update_sched_domain_debugfs 中的 dentry 洩漏 (CVE-2022-48699)

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

    vfio/type1：取消釘選零頁面 (CVE-2022-48700)

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

    USBcore防止巢狀裝置重設呼叫 (CVE-2022-49936)

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

    cifs修正 SMB2_negotiate() 中的小型 mempool 洩漏 (CVE-2022-49938)

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

    vt變更字型前清除選取項目 (CVE-2022-49948)

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

    arm64cacheinfo修正將已簽署錯誤值不正確指派給未簽署 fw_level 的問題 (CVE-2022-49964)

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

    ftrace：修正 ftrace 無作用時 is_ftrace_trampoline 中的 NULL 指標解除參照 (CVE-2022-49977)

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

    net修正 sk_psock_get 中的參照計數錯誤 (2) (CVE-2022-49979)

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

    HIDhidraw修正 hidraw_release() 中的記憶體洩漏 (CVE-2022-49981)

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

    HIDsteam防止在 Steam_{recv,send}_report 中發生 NULL 指標解除參照 (CVE-2022-49984)

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

    bpf不對戳描述符號的陣列範圍檢查使用 tnum_range (CVE-2022-49985)

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

    scsistorvsc從 storvsc_error_wq 移除 WQ_MEM_RECLAIM (CVE-2022-49986)

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

    md：呼叫 md_stop 中的 __md_stop_writes (CVE-2022-49987)

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

    xen/privcmd修正 privcmd_ioctl_dm_op() 的錯誤結束 (CVE-2022-49989)

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

    mm/hugetlb避免 hugetlb_mcopy_atomic_pte 中的 page->mapping 損毀 (CVE-2022-49991)

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

    迴圈：設定迴圈時檢查溢位 (CVE-2022-49993)

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

    bootmem從 put_page_bootmem 中的 kmemleak 移除 vmemmap 頁面 (CVE-2022-49994)

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

    writeback避免移除裝置後發生釋放後使用 (CVE-2022-49995)

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

    btrfs修正 btrfs_get_dev_args_from_path() 中的潛在記憶體洩漏 (CVE-2022-49996)

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

    rxrpc修正 rxrpc 之 sendmsg 中的鎖定 (CVE-2022-49998)

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

    btrfs修正空間快取損毀和潛在的雙重配置 (CVE-2022-49999)

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

    netfilterflowtable修正因為擱置工作而在清理中停滯的流量 (CVE-2022-50000)

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

    xfrmpolicy修正詮釋資料 dst->dev xmit null 指標解除參照 (CVE-2022-50004)

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

    kprobes：不針對已停用的 kprobe 呼叫 disarm_kprobe() (CVE-2022-50008)

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

    driversmd修正潛在的釋放後使用錯誤 (CVE-2022-50022)

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

    netgenl修正原則轉儲存中的錯誤路徑記憶體洩漏 (CVE-2022-50042)

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

    net修正 ndisc_router_discovery() 中潛在的 refcount 洩漏 (CVE-2022-50043)

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

    netfilternf_tables錯誤路徑中可能的模組參照反向溢位 (CVE-2022-50048)

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

    fs/ntfs3修正 ntfs_read_mft 中遺漏的 i_op (CVE-2022-50056)

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

    fs/ntfs3修正 ntfs_update_mftmirr 中的 NULL 解除參照 (CVE-2022-50057)

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

    ceph不洩漏 handle_cap_grant 中的 snap_rwsem (CVE-2022-50059)

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

    virtio_net修正可合併的 XPD_TX 內的記憶體洩漏 (CVE-2022-50065)

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

    btrfs如果交易提交在 prepare_to_relocate() 中失敗會取消設定重新定位控制 (CVE-2022-50067)

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

    drm/ttm修正虛擬 res NULL 指標解除參照錯誤 (CVE-2022-50068)

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

    BPF修正 bpf_sys_bpf() 中潛在的錯誤指標解除參照 (CVE-2022-50069)

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

    NFSv4/pnfs修正開啟中的釋放後使用錯誤 (CVE-2022-50072)

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

    tracing/eprobes使事件探查與 kprobes 和 uprobes 一致 (CVE-2022-50075)

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

    cifs修正延遲關閉時的記憶體洩漏 (CVE-2022-50076)

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

    tracing/eprobes不允許 eprobe 使用 $stack或 % 用於 reg (CVE-2022-50078)

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

    ext4修正 ext4_iomap_begin 中關於 bmap 和 write 爭用的警告 (CVE-2022-50082)

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

    ext4：在 xattr.h 中新增 EXT4_INODE_HAS_XATTR_SPACE 巨集 (CVE-2022-50083)

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

    dm raid修正 raid_status 中的位址清理程式警告 (CVE-2022-50084)

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

    dm raid修正 raid_resume 中的位址清理程式警告 (CVE-2022-50085)

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

    block不允許相同類型 rq_qos 新增超過一次 (CVE-2022-50086)

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

    firmwarearm_scpi確保探查失敗時未指派 scpi_info (CVE-2022-50087)

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

    locking/csd_lock將 csdlock_debug 從 early_param 變更為 __setup (CVE-2022-50091)

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

    dm Thin修正 dm_sm_register_threshold_callback 中的釋放後使用損毀 (CVE-2022-50092)

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

    x86/kprobessinglestepping 後更新 kcb 狀態旗標 (CVE-2022-50096)

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

    video：fbdev：s3fb：使用 memset_io() 前檢查螢幕尺寸 (CVE-2022-50097)

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

    sched/core不要將已從 cpus_mask 排除的 CPU 上的工作重新排入佇列 (CVE-2022-50100)

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

    sched、cpuset修正因清空 cs->cpus_allowed 導致的 dl_cpu_busy() 不穩定 (CVE-2022-50103)

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

    jbd2：修正日誌中止時的宣告 'jh->b_frozen_data == NULL' 失敗 (CVE-2022-50126)

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

    RDMA/irdma修正釋放後使用視窗 (CVE-2022-50137)

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

    RDMA/qedr修正 __qedr_alloc_mr() 中的潛在記憶體洩漏 (CVE-2022-50138)

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

    mm/mempolicy修正 get_nodes 超出邊界存取 (CVE-2022-50147)

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

    驅動程式核心修正 __driver_attach 中的潛在鎖死 (CVE-2022-50149)

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

    usbhost修正 ehci_hcd_ppc_of_probe 中的 refcount 洩漏 (CVE-2022-50153)

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

    of根據記憶體邊界檢查先前核心的 ima-kexec-buffer (CVE-2022-50159)

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

    selinux：在 put_entry() 中新增邊界檢查 (CVE-2022-50200)

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

    PM：hibernate：從休眠狀態恢復時延遲裝置探查 (CVE-2022-50202)

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

    ext2：新增更多的 inode 計數有效性檢查 (CVE-2022-50205)

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

    arm64修正並行設定 insn_emulation sysctls 中的 oops (CVE-2022-50206)

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

    md-raid10：修正 KASAN 警告 (CVE-2022-50211)

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

    netfilternf_tables不允許 CHAIN_ID 參照其他表格 (CVE-2022-50212)

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

    netfilternf_tables不允許 SET_ID 參照其他表格 (CVE-2022-50213)

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

    scsisg允許在移除的裝置上等待命令完成 (CVE-2022-50215)

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

    bpf修正 compute_effect_progs 中的 KASAN 釋放後使用讀取 (CVE-2022-50219)

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

    ttyvt初始化 unicode 畫面緩衝區 (CVE-2022-50222)

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

    KVM：SVM：如果使用者空間插入具有 GIF=0 的中斷，則不要 BUG (CVE-2022-50228)

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

    arm64在 swapper 頁面表格上設定 UXN (CVE-2022-50230)

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

    cryptoarm64/poly1305 - 修正讀取超出邊界問題 (CVE-2022-50231)

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

    arm64在 swapper 頁面表格上設定 UXN (CVE-2022-50232)

    在 nf_tables_updtable 中，如果 nf_tables_table_enable 傳回錯誤，程式會呼叫 nft_trans_destroy 以釋放交易物件。nft_trans_destroy() 會呼叫 list_del()，但從未將交易放置在清單上
    -- 清單標頭全部為零，這會導致 NULL 指標解除參照。(CVE-2023-1095)

    - 在 Linux 核心的 netdevsim 裝置驅動程式的事件排程內發現一個缺陷。此問題是因為不當管理參照計數所導致的。攻擊者可利用此問題，在系統中建立拒絕服務條件。(CVE-2023-2019)

    Linux 核心的 ext4 檔案系統在處理延伸屬性的額外 inode 大小時，會產生釋放後使用弱點。有權限的本機使用者可利用此弱點造成系統當機或其他不明行為。(CVE-2023-2513)

    上游公告對此問題的描述如下：

    本機攻擊者可以利用此弱點，在安裝 Linux 核心的受影響裝置上造成敏感資訊洩漏。攻擊者必須先取得在目標系統上執行高特權程式碼的能力，才能攻擊此弱點。

    此特定弱點存在於 seg6 屬性的處理中。這是未正確驗證使用者提供的資料所導致，攻擊者可利用此缺陷造成讀取範圍超過所分配的緩衝區末尾。
    攻擊者可結合其他弱點，在核心的環境中提升權限並執行任意程式碼。(CVE-2023-2860)

    在 Linux 核心的 btrfs 中，發現 fs/btrfs/relocation.c 的 prepare_to_relocate 中存在釋放後使用弱點。在呼叫 btrfs_ioctl_defrag() 之前，呼叫 btrfs_ioctl_balance() 可能會觸發此潛在缺陷。(CVE-2023-3111)

    在 Linux 核心的 btrfs 檔案系統中，在 fs/btrfs/volumes.c 的 btrfs_get_dev_args_from_path 中發現一個釋放後使用缺陷。利用此瑕疵，有特殊特權的本機攻擊者可造成系統當機或洩漏核心資訊 (CVE-2023-4394)

    在 Linux 核心中發現釋放後使用缺陷。移除磁碟時，系統會呼叫 bdi_unregister 以停止進一步回寫，並等待相關聯的延遲工作完成。不過，wb_inode_writeback_end() 可能會在此完成之後排程頻寬評估工作，這可導致計時器嘗試存取最近釋放的 bdi_writeback。(CVE-2024-0562)

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

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

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1783362244 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
    Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) (CVE-2022-49308)

  - 已解決 Linux 核心中的下列弱點：tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
    Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
    vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
    __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)

  - 已解決 Linux 核心中的下列弱點：ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)

  - 已解決 Linux 核心中的下列弱點：bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
    [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)

  - 已解決 Linux 核心中的下列弱點：capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
    *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)

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

AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1780562693 公告中提及的多個弱點影響。

  - 在 5.16.12 之前的 Linux 核心中發現一個問題。drivers/net/usb/sr9700.c 允許攻擊者透過裝置的特製框架長度，從堆積記憶體取得敏感資訊。(CVE-2022-26966)

  - 已解決 Linux 核心中的下列弱點：kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r
    __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table.
    Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
    aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list :
    show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop :
    warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at
    __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130
    __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm:
    execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP:
    0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
    0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

  - 已解決 Linux 核心中的下列弱點：tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write. [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28;
    int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51;
    int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63 >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \ events/sched/sched_waking/trigger # echo hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid) >> events/sched/sched_switch/trigger [2] BUG: unable to handle page fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09:
    0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3:
    0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX:
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

  - 已解決 Linux 核心中的下列弱點：net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - 已解決 Linux 核心中的下列弱點：net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. (CVE-2024-38553)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
166124	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-020 (ALASKERNEL-5.10-2022-020)	Nessus	Amazon Linux Local Security Checks	2022/10/14	2026/2/26	high
166131	Amazon Linux 2：kernel (ALASKERNEL-5.4-2022-036)	Nessus	Amazon Linux Local Security Checks	2022/10/14	2026/1/26	high
361263	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個漏洞（ALMALINUX9.6：CLSA-2026：1780562693）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high
253769	Linux Distros 未修補的弱點：CVE-2022-50008	Nessus	Misc.	2025/8/24	2026/9/30	medium
165990	Amazon Linux 2核心 --advisory ALAS2-2022-1852 (ALAS-2022-1852)	Nessus	Amazon Linux Local Security Checks	2022/10/10	2026/2/24	high
166118	Amazon Linux 2：kernel (ALASKERNEL-5.15-2022-008)	Nessus	Amazon Linux Local Security Checks	2022/10/14	2026/1/26	high
360687	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783362244）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
361300	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1780562693）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

high

high

medium

high

high

high

high