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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
173140	Amazon Linux 2023 : bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2025/6/9	high
243861	Linux Distros のパッチ未適用の脆弱性: CVE-2023-52934	Nessus	Misc.	2025/8/5	2025/8/5	high

検出

プラグインの検索

high

high