因此，會受到 ALAS2023-2023-132 公告中所提及的多個弱點影響。

    據發現，在某些 AMD CPU 上，RAS (在某些 AMD 文件中亦稱為 RAP - Return Address Predictor，在 Intel 術語中稱為 RSB - Return Stack Buffer) 會在非閒置執行緒之間動態分割。這可讓攻擊者控制相鄰執行緒上的推測執行。(CVE-2022-27672)

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

    ovl針對 memcpy() 目的地使用 buf 彈性陣列 (CVE-2022-49743)

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

    mm/uffd修正 fork() 無分支事件時的 pte 標記 (CVE-2022-49744)

    上游錯誤報告對此問題的描述如下：

    在 Linux 核心的可靠資料包通訊端 (RDS) 通訊協定實作中發現一個瑕疵。rds_rm_zerocopy_callback() 在清單標頭上使用 list_entry()，可造成類型混淆。本機使用者可透過 rds_message_put() 觸發此問題。類型混淆導致 `struct rds_zcopy_info *info` 實際上指向可能由本機使用者控制的其他內容。目前已知此問題的觸發方式，觸發後可造成超出邊界存取和鎖定損毀。(CVE-2023-1078)

    在 Linux 核心的 Framebuffer Console (fbcon) 中發現一個缺陷。為 fbcon_set_font 提供大於 32 的 font->width 和 font->height 時，由於沒有適當的檢查，會發生移位超出邊界，進而導致未定義的行為且可能造成拒絕服務。(CVE-2023-3161)

    drivers/nvmem/brcm_nvram.c 中的 brcm_nvram_parse 未檢查 kzalloc() 的傳回值，這會造成 NULL 指標解除參照 (CVE-2023-3359)

    在 Linux 核心的 vc_screen 中，發現 drivers/tty/vt/vc_screen.c 的 vcs_read 中存在釋放後使用瑕疵。具有本機使用者存取權的攻擊者可利用此瑕疵，來造成系統當機或洩漏核心內部資訊。(CVE-2023-3567)

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

    修正 __free_pages 中的 racy 檢查所造成的頁面損毀 (CVE-2023-52739)

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

    cifs：修正 rdata->read_into_pages() 中的釋放後使用 (CVE-2023-52741)

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

    xfrm/compat：阻止 xfrm_xlate32_attr() 中潛在的 spectre v1 小工具 (CVE-2023-52746)

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

    bpf略過 backtrack_insn 中的無效 kfunc 呼叫 (CVE-2023-52928)

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

    drm/i915修正可能發生的 bit_17 重複釋放 (CVE-2023-52930)

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

    drm/i915避免潛在的 vm 釋放後使用 (CVE-2023-52931)

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

    mm/swapfile: 在 get_swap_pages() 中新增 cond_resched() (CVE-2023-52932)

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

    Squashfs: 修復 xattr_ids 數量處理和功能健全檢查的錯誤 (CVE-2023-52933)

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

    mm/MADV_COLLAPSE捕捉 !none !huge !bad pmd 查閱 (CVE-2023-52934)

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

    mm/khugepaged修正 ->anon_vma 爭用 (CVE-2023-52935)

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

    kernel/irq/irqdomain.c透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-52936)

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

    HVhv_balloon透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-52937)

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

    mmmemcg修正 mem_cgroup_track_foreign_dirty_slowpath() 中的 NULL 指標 (CVE-2023-52939)

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

    mm多代 LRU修正 cgroup 移轉期間發生的當機 (CVE-2023-52940)

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

    cgroup/cpuset修正 update_parent_subparts_cpumask() 中的錯誤檢查 (CVE-2023-52942)

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

    vc_screen：移動 vcs_read() 中的 struct vc_data 指標載入以避免 UAF (CVE-2023-52973)

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

    efi修正 efi_mem_reserve_persistent 中潛在的 NULL 解除參照 (CVE-2023-52976)

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

    net: openvswitch: 修復 ovs_flow_cmd_new 中的流程記憶體流失 (CVE-2023-52977)

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

    squashfs: 強化 squashfs_read_xattr_id_table 中的功能健全檢查 (CVE-2023-52979)

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

    drm/i915修正錯誤擷取和 debugfs 轉儲存期間的要求參照計數 (CVE-2023-52981)

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

    fscache使用 wait_on_bit() 來等待釋放的放棄磁碟區 (CVE-2023-52982)

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

    block、bfq修正 bic_set_bfqq() 中 bfqq 的 uaf (CVE-2023-52983)

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

    bpf、sockmap複製接聽程式時檢查任何 tcp_bpf_prots (CVE-2023-52986)

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

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

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

  - 已解決 Linux 核心中的下列弱點：mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 (mm/madvise: add file and shmem support to MADV_COLLAPSE) we make the following change to find_pmd_or_thp_or_none(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL;
    + if (pmd_none(pmde)) + return SCAN_PMD_NONE; This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd. Such codepaths include: A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER already in the pagecache. B) In retract_page_tables(), if we fail to grab mmap_lock for the target mm/address. In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc). Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd. However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds. One such example that could leak through are swap entries. The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd. We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch. The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state. For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit. Covering all 4 cases for x86 (all checks done on the same pmd value): 1) pmd_present() && pmd_trans_huge() All we actually know here is that the PSE bit is set. Either: a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE is set. => huge-pmd b) We are currently racing with __split_huge_page(). The danger here is that we proceed as-if we have a huge-pmd, but really we are looking at a pte-mapping-pmd. So, what is the risk of this danger? The only relevant path is: madvise_collapse() -> collapse_pte_mapped_thp() Where we might just incorrectly report back success, when really the memory isn't pmd-backed. This is fine, since split could happen immediately after (actually) successful madvise_collapse(). So, it should be safe to just assume huge-pmd here. 2) pmd_present() && !pmd_trans_huge() Either: a) PSE not set and either PRESENT or PROTNONE is. => pte-table-mapping pmd (or PROT_NONE) b) devmap. This routine can be called immediately after unlocking/locking mmap_lock -- or called with no locks held (see khugepaged_scan_mm_slot()), so previous VMA checks have since been invalidated. 3) !pmd_present() && pmd_trans_huge() Not possible. 4) !pmd_present() && !pmd_trans_huge() Neither PRESENT nor PROTNONE set => not present I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path). Also, add a comment above find_pmd_or_thp_or_none() ---truncated--- (CVE-2023-52934)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
173140	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2026/2/24	high
243861	Linux Distros 未修補的弱點：CVE-2023-52934	Nessus	Misc.	2025/8/5	2025/10/27	high

偵測

搜尋 Plugin

high

high