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

  - 在 Linux 核心中，已解決下列弱點： bpf: Fix UAF due to race between btf_try_get_module and load_module While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF. However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE. This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future. There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function). An illustration of the race: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ...
    bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug. A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments: 1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely. 2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior. (CVE-2022-49236)

請注意，Nessus 依賴供應商報告的套件存在。

遠端 Redhat Enterprise Linux 9 主機上安裝的多個套件受到 RHSA-2023:2458 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * net/bluetooth/l2cap_core.c 中 l2cap_connect 和 l2cap_le_connect_req 中的釋放後使用問題 (CVE-2022-42896)

    * net/ulp接聽 ULP 通訊端時發生釋放後使用 (CVE-2023-0461)

    * cpuAMD CPU 可能會暫時執行超出無條件直接分支的範圍 (CVE-2021-26341)

    * FBIOPUT_VSCREENINFO ioctl 的惡意資料可能造成 OOB 寫入記憶體 (CVE-2021-33655)

    * drivers/tty/tty_buffers.c 中可能存在爭用情形 (CVE-2022-1462)

    * KVMkvm_mmu_invpcid_gva 中的 NULL 指標解除參照 (CVE-2022-1789)

    * free_pipe_info() 中的釋放後使用可導致權限提升 (CVE-2022-1882)

    * KVMnVMX結束巢狀來賓時遺漏 IBPB可導致 Spectre v2 攻擊 (CVE-2022-2196)

    * netfilternf_conntrack_irc 訊息處理問題 (CVE-2022-2663)

    * xfrm_probe_algs 中的爭用情形可導致 OOB 讀取/寫入 (CVE-2022-3028)

    * 檔案 net/ipv4/fib_semantics.c 的 fib_nh_match 發生超出邊界讀取 (CVE-2022-3435)

    * mm/hugetlb.c 中 hugetlb_no_page() 的爭用情形 (CVE-2022-3522)

    * ipv6_renew_options() 中發生記憶體洩漏 (CVE-2022-3524)

    * do_ipv6_setsockopt 中有關 icsk->icsk_af_ops 的資料爭用 (CVE-2022-3566)

    * sk->sk_prot 發生資料爭用 (CVE-2022-3567)

    * net/bluetooth/l2cap_core.c 檔案的 l2cap_recv_acldata 中發生記憶體洩漏 (CVE-2022-3619)

    * 在 mm/gup.c 中follow_page_pte 中的拒絕服務這是因為 pte 項目毒害所導致 (CVE-2022-3623)

    * 在 devlink_param_get 中的 devlink 重新載入失敗後發生釋放後使用 (CVE-2022-3625)

    * brcmfmac 中發生 USB 可存取緩衝區溢位 (CVE-2022-3628)

    * net/bluetooth/l2cap_core.c 中 l2cap_conn_del 中的釋放後使用瑕疵 (CVE-2022-3640)

    * 當 intel_gvt_dma_map_guest_page 函式失敗時在 split_2MB_gtt_entry 中發生雙重釋放 (CVE-2022-3707)

    * mptcp中斷連線時子流程遊走中的 NULL 指標解除參照 (CVE-2022-4128)

    * l2tp清除 sk_user_data 時遺漏鎖定可導致 NULL 指標解除參照 (CVE-2022-4129)

    * igmp當開啟和關閉 inet 通訊端時ip_check_mc_rcu 中發生釋放後使用 (CVE-2022-20141)

    * 使用 IMA 的鎖定繞過 (CVE-2022-21505)

    * drivers/net/can/usb/usb_8dev.c 中的 usb_8dev_start_xmit 發生雙重釋放 (CVE-2022-28388)

    * 網路後端可能造成 Linux netfront 使用已釋放的 SKB (XSA-405) (CVE-2022-33743)

    * unmap_mapping_range() 與 VM_PFNMAP 對應上的 munmap() 爭用導致過時 TLB 項目 (CVE-2022-39188)

    * TLB 排清作業在某些 KVM_VCPU_PREEMPTED 中遭到錯誤處理進而導致來賓運作失常 (CVE-2022-39189)

    * cfg80211_update_notlisted_nontrans() 中的 u8 溢位問題 (CVE-2022-41674)

    * 與分葉 anon_vma 重複使用相關的釋放後使用 (CVE-2022-42703)

    * 在 net/wireless/scan.c 中bss_ref_get 中的 bss_ref_get 存在釋放後使用 (CVE-2022-42720)

    * net/wireless/scan.c 的 cfg80211_add_nontrans_list 中存在 BSS 清單損毀 (CVE-2022-42721)

    * P2P 裝置信標保護中的拒絕服務 (CVE-2022-42722)

    * usbmon 驅動程式中的記憶體損毀 (CVE-2022-43750)

    * 流量控制子系統中的 NULL 指標解除參照 (CVE-2022-47929)

    * rawv6_push_pending_frames 中發生 NULL 指標解除參照 (CVE-2023-0394)

    * qdisc_graft() 中的爭用情形導致釋放後使用 (CVE-2023-0590)

    * fs/cifs/connect.c 中的無效指標主機名稱造成的釋放後使用 (CVE-2023-1195)

    * tipc_conn_close 中的拒絕服務 (CVE-2023-1382)

    如需安全性問題的詳細資料，包括影響、CVSS 分數、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

    其他變更：

    如需有關此發行版本的詳細變更資訊，請參閱可從「參考資料」一節連結的 Red Hat Enterprise Linux 9.2 版本資訊。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
225146	Linux Distros 未修補弱點：CVE-2022-49236	Nessus	Misc.	2025/3/5	2025/10/17	high
175477	RHEL 9：核心 (RHSA-2023:2458)	Nessus	Red Hat Local Security Checks	2023/5/13	2025/9/10	high

偵測

搜尋 Plugin

high

high