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

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

    drm修正因 drmm_mode_config_init() 引起的潛在 null-ptr-deref (CVE-2022-50556)

    在 Linux 核心以 io_uring 處理 IORING_OP_SOCKET 作業的過程中發現一個雙重釋放弱點。 (CVE-2023-1032)

    由於初始化期間的類型混淆問題，Linux 核心中的 tun 和 tap 通訊端將其通訊端 UID 硬式編碼為 0 (即 root)。雖然這通常是正確的，因為 TUN/TAP 裝置需要 CAP_NET_ADMIN，但也存在例外情況。通訊端 UID 可用於網路篩选和路由，因此可能導致 TUN/TAP 通訊端管理方式錯誤，進而可能繞過以 UID 為基礎的網路篩選器。(CVE-2023-1076)

    核心：pick_next_rt_entity() 中存在類型混淆弱點，此弱點可導致記憶體損毀。(CVE-2023-1077)

    在使用者卸離 rc 裝置的方式中在 Linux 核心整合式紅外線接收器/收發器驅動程式中發現一個瑕疵。本機使用者可利用此缺陷使系統當機，或可能提升其在系統中的權限。(CVE-2023-1118)

    Linux 核心流量控制索引篩選器 (tcindex) 中的釋放後使用弱點可被利用來提升本機權限。tcindex_delete 函式在刪除基礎結構時未正確停用篩選器，從而會在稍後導致重複釋放該結構。本機攻擊者可利用此弱點來將特權提升為根權限。我們建議使用者升級過去的認可 8c710f75256bb3cf05ac7b1672c82b92c43f3d28。(CVE-2023-1829)

    啟用純文字 IBRS (非增強型 IBRS) 時，spectre_v2_user_select_mitigation() 中的邏輯會判定不需要 STIBP。IBRS 位元可暗中防止跨執行緒分支目標插入。但是，使用舊版 IBRS 時，由於效能原因，IBRS 位元會在傳回至使用者空間時遭到清除，這會使使用者空間執行緒容易受到 STIBP 防範的跨執行緒分支目標插入攻擊。(CVE-2023-1998)

    在 Linux 核心中 fs/hfsplus/super.c 的 hfsplus_put_super 中發現釋放後使用缺陷。本機使用者可利用此缺陷造成拒絕服務。(CVE-2023-2985)

    在 6.2.3 版之前的 Linux 核心中，發現 lib/kobject.c 存在問題。攻擊者可藉由 root 存取權觸發爭用情形，進而導致 fill_kobj_path 超出邊界寫入。(CVE-2023-45863)

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

    vfio/type1防止透過 exec() 發生 locked_vm 的反向溢位 (CVE-2023-53171)

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

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

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

    netfilterx_tables修正建立新 netns 時錯誤路徑上的 percpu 計數器區塊洩漏 (CVE-2023-53200)

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

    PMdomains使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53202)

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

    驅動程式核心位置在傳回 false 之前釋放結構 acpi_pld_info *pld (CVE-2023-53211)

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

    arm64efi使 efi_rt_lock 成為 raw_spinlock (CVE-2023-53216)

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

    watchdog修正 watchdog_cdev_register 中的 kmemleak (CVE-2023-53234)

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

    xsk在 Tx 路徑中更早檢查 IFF_UP (CVE-2023-53240)

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

    firmwaredmi-sysfs修正 dmi_sysfs_register_handle 中的 null-ptr-deref (CVE-2023-53250)

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

    cacheinfo修正 shared_cpu_map 以處理不同層級的共用快取 (CVE-2023-53254)

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

    VMCI在呼叫 get_user_pages_fast() 之後檢查 context->notify_page 以避免 GPF (CVE-2023-53259)

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

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

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

    udf不針對內嵌檔案寫入失敗更新檔案長度 (CVE-2023-53295)

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

    rbd避免當 rbd_dev_create() 失敗時在 do_rbd_add() 中發生釋放後使用 (CVE-2023-53307)

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

    genirq/ipi修正 irq_data_get_affinity_mask() 中的 NULL 指標解除參照 (CVE-2023-53332)

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

    USB修正因使用 debugfs_lookup() 而發生的記憶體洩漏 (CVE-2023-53359)

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

    block輪詢時仔細檢查 NULL bdev (CVE-2023-53366)

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

    cryptoseqiv - 正確處理 EBUSY (CVE-2023-53373)

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

    NFSD修正 nfsd4_ssc_umount_item 的洩漏參照計數 (CVE-2023-53381)

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

    driversbasedd使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53390)

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

    trace/blktrace透過使用 debugfs_lookup() 修正記憶體洩漏 (CVE-2023-53408)

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

    drivers基礎元件修正因使用 debugfs_lookup() 發生的記憶體洩漏問題 (CVE-2023-53409)

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

    PMEM修正使用 debugfs_lookup() 時發生的記憶體洩漏問題 (CVE-2023-53411)

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

    objtool修正 create_static_call_sections() 中的記憶體洩漏 (CVE-2023-53423)

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

    cifs修正損毀 MR 清單時的警告和 UAF (CVE-2023-53427)

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

    ipv6在 nexthop 計算中新增所有同級的 lwtunnel 封裝大小 (CVE-2023-53477)

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

    iommu修正 iommu_group_alloc() 中的錯誤回溯 (CVE-2023-53482)

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

    cryptoxts - 正確處理 EBUSY (CVE-2023-53494)

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

    udf請勿合併非常長的範圍 (CVE-2023-53506)

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

    io_uring修正 fs 不支援 nowait 緩衝讀取時發生的 fget 洩漏 (CVE-2023-53511)

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

    sctp在 sctp_stream_priorities 中新增 refcnt 以避免巢狀迴圈 (CVE-2023-53590)

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

    驅動程式核心修正 device_add() 中的資源洩漏 (CVE-2023-53594)

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

    nfsd清理 COPY 程式碼路徑中的潛在 nfsd_file refcount 洩漏 (CVE-2023-53606)

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

    irqchip修正 platform_irqchip_probe 中的 refcount 洩漏 (CVE-2023-53610)

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

    nvme-tcp錯誤復原期間不存取已釋放的通訊端 (CVE-2023-53643)

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

    srcu如果使用 SRCU_SIZE_SMALL則將工作委派給開機 cpu (CVE-2023-53671)

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

    drm/i915修正系統在 fbdev 未初始化的情況下暫停 (CVE-2023-53678)

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

    udf偵測連結至目錄階層的系統 inode (CVE-2023-53695)

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

    ring-buffer處理 rb_move_tail 和 rb_check_pages 之間的爭用 (CVE-2023-53709)

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

    KVMVMX修正因未初始化 current_vmcs 而造成的當機 (CVE-2023-53756)

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

    dm 快取釋放 btracker_destroy 中背景追踪器的佇列工作 (CVE-2023-53765)

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

    blk-iocost修正 calc_lcoefs() 中的除以 0 錯誤 (CVE-2023-53783)

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

    iommu/amd改善頁面錯誤錯誤報告 (CVE-2023-53789)

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

    bpf將已配置物件從 bpf 記憶體配置器的平台歸零 (CVE-2023-53790)

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

    PCI修正放置具有 .end = 零的有效 root 匯流排資源 (CVE-2023-53814)

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

    迴圈指派前的 loop_set_status_from_info() 檢查 (CVE-2023-53820)

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

    usbearlyxhci-dbc修正潛在的越界記憶體存取 (CVE-2023-53840)

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

    KVM如果 coalesced MMIO 取消註冊失敗則破壞目標裝置 (CVE-2023-54024)

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

    cryptoesiv - 正確處理 EBUSY (CVE-2023-54046)

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

    iommu/amd為 ivrs_acpihid 命令行參數新增長度限制 (CVE-2023-54057)

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

    blk-cgroup在完成 pd_free_fn() 之後放置父項 refcount (CVE-2023-54107)

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

    ledsled-core修正 of_led_get() 中的 refcount 洩漏 (CVE-2023-54190)

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

    tty修正 tty_driver_lookup_tty() 中的越界存取 (CVE-2023-54198)

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

    netfilterebtables修正表格 blob 釋放後使用 (CVE-2023-54243)

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

    cifsMR 配置失敗時修正遺失的破壞 smbd 連線 (CVE-2023-54260)

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

    ext4拒絕在卸載時建立 ea 區塊 (CVE-2023-54305)

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

    nettls避免在 tx_lock 上懸置工作 (CVE-2023-54306)

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

    dm flakey不損毀零頁面 (CVE-2023-54317)

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

    驅動程式核心修正 device_add() 中潛在的 null-ptr-deref (CVE-2023-54321)

    核心：ctnetlink_create_conntrack() 中的參照計數洩漏問題 (CVE-2023-7192)

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

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

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

  - iommu/amd改善頁面錯誤錯誤報告如果裝置群組的 IOMMU 網域未正確設定則可能會遇到 IOMMU 頁面錯誤。目前的頁面錯誤處理常式假設網域一律設定且會命中 NULL 指標解除參照 (請參閱以下記錄範例)。讓我們檢查網域是否已設定並記錄適當的訊息。範例記錄 ---------- amdgpu 0000:00:01.0: amdgpuSE 1、每個 SE 1 的 SH、每個 SH 8 的 CU、active_cu_number 6 錯誤核心 NULL 指標解除參照、位址0000000000000058 #PF核心模式中的監督讀取存取 error_code(0x0000) - 不存在頁面 PGD 0 P4D 0 Oops0000 [#1] PREEMPT SMP NOPTI CPU2 PID56 通訊irq/24-AMD-Vi 未受污染的 6.2 .0-rc2+ #89 硬體名稱xxx RIP
    0010:report_iommu_fault+0x11/0x90 [...] 呼叫追踪 <TASK> amd_iommu_int_thread+0x60c/0x760
    __pfx_irq_thread_fn+0x10/0x10 irq_thread_fn+0x1f/0x60 irq_thread+0xea/0x1a0 ? preempt_count_add+0x6a/0xa0 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xe9/0x110 ?
    __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> [joro編輯提交訊息] (CVE-2023-53789)

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

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

  - 已解決 Linux 核心中的下列弱點：firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. (CVE-2022-50087)

  - 已解決 Linux 核心中的下列弱點：wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG:
    KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ...
    kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ...
    </TASK> The root cause of the problem is that the comparison order of prate_section in
    _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, pregulation and pbandwidth are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of prate_section dose not obey such order requirement, therefore when prate_section is HT, when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the
    _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing
    _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of prate_section, this may cause the value of rate_section to not be from 0 to 5. In addition, commit 21e4b0726dc6 not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit. (CVE-2022-50279)

  - 已解決 Linux 核心中的下列弱點：wifi: ath11k: fix monitor mode bringup crash When the interface is brought up in monitor mode, it leads to NULL pointer dereference crash. This crash happens when the packet type is extracted for a SKB. This extraction which is present in the received msdu delivery path,is not needed for the monitor ring packets since they are all RAW packets.
    Hence appending the flags with RX_FLAG_ONLY_MONITOR to skip that extraction. Observed calltrace: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000064 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable:
    4k pages, 48-bit VAs, pgdp=0000000048517000 [0000000000000064] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ath11k_pci ath11k qmi_helpers CPU: 2 PID: 1781 Comm: napi/-271 Not tainted 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6 Hardware name:
    Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] lr :
    ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k] sp : ffff80000ef5bb10 x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0 x26: ffff000014a91ed0 x25: 0000000000000000 x24:
    0000000000000000 x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600 x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006 x17: 736564203634343a x16: 656e694c20657079 x15:
    0000000000000143 x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8 x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff x8 : 0000000000000003 x7 : 0000000000017fe8 x6 :
    ffff80000a579ce8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052 Call trace: ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k] ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k] ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k] ath11k_dp_service_srng+0x234/0x338 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]
    __napi_poll+0x5c/0x190 napi_threaded_poll+0xf0/0x118 kthread+0xf4/0x110 ret_from_fork+0x10/0x20 Tested-on:
    QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 (CVE-2022-50627)

  - 已解決 Linux 核心中的下列弱點：mm: hugetlb: fix UAF in hugetlb_handle_userfault The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ (CVE-2022-50630)

  - 已解決 Linux 核心中的下列弱點：PCI: Fix pci_device_is_present() for VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or 0 is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned false in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag] (CVE-2022-50636)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
173340	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-138)	Nessus	Amazon Linux Local Security Checks	2023/3/23	2026/2/10	high
277896	Linux Distros 未修補的弱點：CVE-2023-53789	Nessus	Misc.	2025/12/9	2026/10/17	medium
360579	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc多個弱點（ALMALINUX9.2：CLSA-2026：1767864313）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

medium

high