It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2023-132 advisory.

    It has been discovered that on some AMD CPUs, the RAS (Return Address Stack, also called RAP - Return     Address Predictor - in some AMD documentation, and RSB - Return Stack Buffer - in Intel terminology) is     dynamically partitioned between non-idle threads.  This allows an attacker to control speculative     execution on the adjacent thread. (CVE-2022-27672)

    In the Linux kernel, the following vulnerability has been resolved:

    ovl: Use buf flexible array for memcpy() destination (CVE-2022-49743)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/uffd: fix pte marker when fork() without fork event (CVE-2022-49744)

    The upstream bug report describes this issue as follows:

    A flaw found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The     rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user     can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info`     actually points to something else that is potentially controlled by local user. It is known how to trigger     this, which causes an OOB access, and a lock corruption. (CVE-2023-1078)

    A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing a font->width and     font->height greater than 32 to the fbcon_set_font, since there are no checks in place, a shift-out-of-     bounds occurs, leading to undefined behavior and possible denial of service. (CVE-2023-3161)

    brcm_nvram_parse in drivers/nvmem/brcm_nvram.c lacks check of the return value of kzalloc() and will cause     the NULL Pointer Dereference (CVE-2023-3359)

    A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux     Kernel. In this flaw an attacker with local user access may lead to a system crash or a leak of internal     kernel information. (CVE-2023-3567)

    In the Linux kernel, the following vulnerability has been resolved:

    Fix page corruption caused by racy check in __free_pages (CVE-2023-52739)

    In the Linux kernel, the following vulnerability has been resolved:

    cifs: Fix use-after-free in rdata->read_into_pages() (CVE-2023-52741)

    In the Linux kernel, the following vulnerability has been resolved:

    xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() (CVE-2023-52746)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Skip invalid kfunc call in backtrack_insn (CVE-2023-52928)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Fix potential bit_17 double-free (CVE-2023-52930)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Avoid potential vm use-after-free (CVE-2023-52931)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/swapfile: add cond_resched() in get_swap_pages() (CVE-2023-52932)

    In the Linux kernel, the following vulnerability has been resolved:

    Squashfs: fix handling and sanity checking of xattr_ids count (CVE-2023-52933)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups (CVE-2023-52934)

    In the Linux kernel, the following vulnerability has been resolved:

    mm/khugepaged: fix ->anon_vma race (CVE-2023-52935)

    In the Linux kernel, the following vulnerability has been resolved:

    kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() (CVE-2023-52936)

    In the Linux kernel, the following vulnerability has been resolved:

    HV: hv_balloon: fix memory leak with using debugfs_lookup() (CVE-2023-52937)

    In the Linux kernel, the following vulnerability has been resolved:

    mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() (CVE-2023-52939)

    In the Linux kernel, the following vulnerability has been resolved:

    mm: multi-gen LRU: fix crash during cgroup migration (CVE-2023-52940)

    In the Linux kernel, the following vulnerability has been resolved:

    cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask() (CVE-2023-52942)

    In the Linux kernel, the following vulnerability has been resolved:

    vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF (CVE-2023-52973)

    In the Linux kernel, the following vulnerability has been resolved:

    efi: fix potential NULL deref in efi_mem_reserve_persistent (CVE-2023-52976)

    In the Linux kernel, the following vulnerability has been resolved:

    net: openvswitch: fix flow memory leak in ovs_flow_cmd_new (CVE-2023-52977)

    In the Linux kernel, the following vulnerability has been resolved:

    squashfs: harden sanity check in squashfs_read_xattr_id_table (CVE-2023-52979)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915: Fix request ref counting during error capture & debugfs dump (CVE-2023-52981)

    In the Linux kernel, the following vulnerability has been resolved:

    fscache: Use wait_on_bit() to wait for the freeing of relinquished volume (CVE-2023-52982)

    In the Linux kernel, the following vulnerability has been resolved:

    block, bfq: fix uaf for bfqq in bic_set_bfqq() (CVE-2023-52983)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener (CVE-2023-52986)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: 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)

Note that Nessus relies on the presence of the package as reported by the vendor.

したがって、ALAS2023-2023-132 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    一部の AMD CPU で、RAS (Return Address Stack、一部の AMD のドキュメントでは RAP - Return Address Predictor とも呼ばれ、Intel の用語では RSB - Return Stack Buffer と呼ばれる) が、非アイドルスレッド間で動的に分割されることが判明しました。これにより、攻撃者が隣接するスレッドの投機的実行を制御する可能性があります。(CVE-2022-27672)

    Linux カーネルで、以下の脆弱性が解決されています。

    ovlmemcpy() の宛先に対して buf 柔軟配列を使用しますCVE-2022-49743

    Linux カーネルで、以下の脆弱性が解決されています。

    mm/uffdfork イベントなしで fork() を行う際の pte マーカーを修正しますCVE-2022-49744

    Upstream バグレポートでは、この問題について次のように説明されています。

    RDS (Reliable Datagram Sockets) プロトコルの Linux カーネルに欠陥が見つかりました。rds_rm_zerocopy_callback() は、リストの先頭で list_entry() を使用するため、型の取り違え (Type Confusion) を引き起こします。ローカルユーザーは、rds_message_put() でこれをトリガーできます。型の取り違えにより、「struct rds_msg_zcopy_info *info」は、ローカルユーザーによって制御されている可能性のある他のものを実際に指し示します。これをトリガーする方法が知られています。これにより、OOB アクセスとロック破損が引き起こされます。(CVE-2023-1078)

    Linux カーネルのフレームバッファコンソール (fbcon) で欠陥が見つかりました。fbcon_set_font に 32 より大きい font->width と font->height を指定すると、チェックが行われないため、shift-out-of-bounds が発生し、未定義の動作やサービス拒否を引き起こす可能性があります。(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 に、メモリ解放後使用 (Use After Free) の欠陥が見つかりました。この欠陥により、ローカルのユーザーアクセス権限を持つ攻撃者がシステムをクラッシュさせたりカーネル内部情報を漏洩させたりする可能性があります。(CVE-2023-3567)

    Linux カーネルで、以下の脆弱性は解決されています。

    __free_pages のレーシーなチェックによって引き起こされたページ破損を修正します (CVE-2023-52739)

    Linux カーネルで、以下の脆弱性は解決されています。

    cifs: rdata->read_into_pages() の use-after-free を修正します (CVE-2023-52741)

    Linux カーネルで、以下の脆弱性は解決されています。

    xfrm/compat: xfrm_xlate32_attr() の潜在的な specter v1 ガジェットを防止します (CVE-2023-52746)

    Linux カーネルで、以下の脆弱性が解決されています。

    bpfbacktrack_insn で無効な kfunc 呼び出しをスキップしますCVE-2023-52928

    Linux カーネルで、以下の脆弱性は解決されています。

    drm/i915潜在的な bit_17 の二重解放を修正しますCVE-2023-52930

    Linux カーネルで、以下の脆弱性は解決されています。

    drm/i915潜在的な vm use-after-free を回避します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.cdebugfs_lookup() を使用したメモリリークを修正しますCVE-2023-52936

    Linux カーネルで、以下の脆弱性が解決されています。

    HVhv_balloondebugfs_lookup() を使用したメモリリークを修正しますCVE-2023-52937

    Linux カーネルで、以下の脆弱性が解決されています。

    mmmemcgmem_cgroup_track_foreign_dirty_slowpath() で NULL ポインターを修正しますCVE-2023-52939

    Linux カーネルで、以下の脆弱性が解決されています。

    mmmulti-gen LRUcgroup 移行中のクラッシュを修正しますCVE-2023-52940

    Linux カーネルで、以下の脆弱性が解決されています。

    cgroup/cpusetupdate_parent_subparts_cpumask() の誤ったチェックを修正しますCVE-2023-52942

    Linux カーネルで、以下の脆弱性が解決されています。

    vc_screen: vcs_read() の中の struct vc_data ポインターのロードを移動し、UAF を回避 (CVE-2023-52973)

    Linux カーネルで、以下の脆弱性は解決されています。

    efiefi_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 カーネルで、以下の脆弱性が解決されています。

    fscachewait_on_bit() を使用して、破棄されたボリュームの解放を待機しますCVE-2023-52982]

    Linux カーネルで、以下の脆弱性が解決されています。

    ブロック、bfqbic_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 は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

因此，會受到 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 依賴供應商報告的套件存在。

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 依赖供应商报告的程序包是否存在进行判断。

因此，该软件受到 ALAS2023-2023-132 公告中提及的多个漏洞影响。

    已发现在某些 AMD CPU 上，RAS（返回地址堆栈，在某些 AMD 文档中也称为 RAP [返回地址预测器]，在 Intel 术语中也称为 RSB [返回堆栈缓冲区]）在非空闲线程之间进行动态分区。攻击者可利用此漏洞，控制邻近线程上的推测执行。(CVE-2022-27672)

    在 Linux 内核中，以下漏洞已修复：

    ovl将 buf 灵活数组用于 memcpy() 目标 (CVE-2022-49743)

    在 Linux 内核中，以下漏洞已修复：

    mm/uffd在无 fork 事件的情况下进行 fork() 时修复 pte 标记CVE-2022-49744

    上游缺陷报告对此问题的描述如下：

    在 Linux 内核的可靠数据报套接字 (RDS) 协议实现中发现了一个缺陷。rds_rm_zerocopy_callback() 在造成类型混淆的列表标头上使用 list_entry()。本地用户可通过 rds_message_put() 触发此漏洞。类型混淆导致“struct rds_msg_zcopy_info *info”实际上指向可能由本地用户控制的其他内容。触发此漏洞的方式已为用户所知，该漏洞将导致越界访问和锁定损坏。(CVE-2023-1078)

    在 Linux 内核的 Framebuffer 控制台 (fbcon) 中发现了一个缺陷。向 fbcon_set_font 提供大于 32 的 font->width 和 font->height 时，由于检查不到位，会发生 shift 越界，从而导致不明行为并可能导致拒绝服务。(CVE-2023-3161)

    drivers/nvmem/brcm_nvram.c 中的 brcm_nvram_parse 缺少对 kzalloc() 的返回值的检查，将导致空指针取消引用缺陷 (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_COLLAPSEcatch !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() 中的空指针 (CVE-2023-52939)

    在 Linux 内核中，以下漏洞已修复：

    mmmulti-gen LRU修复 cgroup 迁移期间发生的崩溃 (CVE-2023-52940)

    在 Linux 内核中，以下漏洞已修复：

    cgroup/cpuset修复 update_parent_subparts_cpumask() 中的错误检查 (CVE-2023-52942)

    在 Linux 内核中，以下漏洞已修复：

    vc_screen：移动 vcs_read() 中的结构 vc_data 指针加载以避免 UAF (CVE-2023-52973)

    在 Linux 内核中，以下漏洞已修复：

    efi修复 efi_mem_reserve_persistent 中潜在的空取消引用 (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 内核中，以下漏洞已修复：

    blockbfq修复 bic_set_bfqq() 中 bfqq 的 uafCVE-2023-52983

    在 Linux 内核中，以下漏洞已修复：

    bpfsockmap克隆侦听器时检查任何 tcp_bpf_prots (CVE-2023-52986)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	Name	Product	Family	Published	Updated	Severity
173140	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	3/21/2023	6/9/2025	high
243861	Linux Distros Unpatched Vulnerability : CVE-2023-52934	Nessus	Misc.	8/5/2025	8/5/2025	high
173140	Amazon Linux 2023 : bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	3/21/2023	6/9/2025	high
243861	Linux Distros のパッチ未適用の脆弱性: CVE-2023-52934	Nessus	Misc.	8/5/2025	8/5/2025	high
173140	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	3/21/2023	6/9/2025	high
243861	Linux Distros 未修補的弱點：CVE-2023-52934	Nessus	Misc.	8/5/2025	8/5/2025	high
243861	Linux Distros 未修补的漏洞：CVE-2023-52934	Nessus	Misc.	8/5/2025	8/5/2025	high
173140	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	3/21/2023	6/9/2025	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high

high