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

    在 Linux 核心 6.4.2 及其之前版本的 USB 子系統中發現一個問題。drivers/usb/core/sysfs.c 的 read_descriptors 中存在一個超出邊界和損毀問題。(CVE-2023-37453)

    nf_osf_match_one() 中的 nftables 超出邊界讀取弱點 (CVE-2023-39189)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。xt_u32 模組未驗證 xt_u32 結構中的欄位。本機特權攻擊者可利用此缺陷，透過以陣列邊界外的值設定尺寸欄位來觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39192)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。sctp_mt_check 未驗證 flag_count 欄位。本機特權 (CAP_NET_ADMIN) 攻擊者可利用此缺陷觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39193)

    Linux 核心的 kmalloc_reserve() 中存在整數溢位弱點，本機使用者可藉此造成系統當機，或在某些情況下取得在核心空間中執行程式碼的權限。(CVE-2023-42752)

    上游認可對此問題的描述如下：

    ip_set_hash_netportnet 中遺漏的 IP_SET_HASH_WITH_NET0 巨集可導致程式使用錯誤的「CIDR_POS(c)」來計算陣列位移，進而導致整數反向溢位。因此，這會造成 slab 超出邊界存取。(CVE-2023-42753)

    在 rsvp_change() 中發現一個瑕疵。根本原因是 slab 超出邊界存取，但由於原始指標的位移是由使用者完全控制的 `unsign int`，因此該行為通常是環境指標存取。(CVE-2023-42755)

    在 6.5.3 之前版本的 Linux 核心中，發現 IGB 驅動程式中的 drivers/net/ethernet/intel/igb/igb_main.c 存在問題。緩衝區大小可能不足以容納大於 MTU 的框架。(CVE-2023-45871)

    Linux 核心的 net/sched: sch_hfsc (HFSC qdisc 流量控制) 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    如果具有連結共用曲線的類別 (即設定了 HFSC_FSC 旗標) 的父項沒有連結共用曲線，則 init_vf() 會呼叫父項上的 vttree_insert()，但會略過 update_vf( ) 上的 vttree_remove()。這會留下可造成釋放後使用的懸置指標。

    建議升級過去的 commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f。(CVE-2023-4623)

    Linux 核心的 net/sched: sch_qfq 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    當使用 plug qdisc 做為 qfq qdisc 的類別時，傳送網路封包會在 qfq_dequeue() 中觸發釋放後使用弱點，這是因為 sch_plug 的 .peek 處置程式不正確，且缺少 agg_dequeue() 中的錯誤檢查所致。

    建議升級過去的 commit 8fc134fee27f2263988ae38920bc03da416b03d8。(CVE-2023-4921)

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

    netfilter：nftables：exthdr：修復 4 位元組堆疊 OOB 寫入弱點

    如果 priv->len 是 4 的倍數，則 dst[len / 4] 可寫入超過目的地陣列，進而導致堆疊損毀。

    這個建構對於清理暫存器的其餘部分是必要的，前提是 ->len 不是暫存器大小的倍數，因此就像 nft_payload.c 一樣，將其做為條件。

    錯誤是在 4.1 週期中新增，並在新增 tcp/sctp 和 ip 選項支援時複製/繼承。

    由零時差計劃專案報告的錯誤 (ZDI-CAN-21950、ZDI-CAN-21951、ZDI-CAN-21961)。(CVE-2023-52628)

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

    USB核心不覆寫 hub_port_init() 中的 udev->descriptor 修正爭用 (CVE-2023-52886)

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

    netfilteripset新增 ip_set_hash_netportnet.c 遺漏的 IP_SET_HASH_WITH_NET0 巨集 (CVE-2023-53179)

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

    af_unix修正 user->unix_inflight 的資料爭用。 (CVE-2023-53204)

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

    KVMnSVM根據 L1 狀態而不是 L2 狀態載入 L1 的 TSC 乘數 (CVE-2023-53208)

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

    md/raid5-cache修正 r5l_flush_stripe_to_raid() 的 null-ptr-deref (CVE-2023-53210)

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

    drm/msm/mdp5不洩漏某些平面狀態 (CVE-2023-53324)

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

    pstore/ram檢查 init 期間空白 przs 的開始 (CVE-2023-53331)

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

    lwt修正 BPF xmit ops 的傳回值 (CVE-2023-53338)

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

    skbuffskb_segment在使用 skbuff 片段之前呼叫零複製函式 (CVE-2023-53354)

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

    追踪修正 cpu 緩衝區寫入和交換之間的爭用問題 (CVE-2023-53368)

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

    ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至 Timer (CVE-2023-53395)

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

    xsk修正通訊端清理期間的 xsk_diag 釋放後使用錯誤 (CVE-2023-53426)

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

    x86/MCE發生 AMD Zen IF 毒害錯誤時一律儲存 CS 暫存器 (CVE-2023-53438)

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

    HIDmultitouch更正 hidinput input_dev 名稱的 devm 裝置參照 (CVE-2023-53454)

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

    scsiqla4xxx新增剖析 nlattrs 時的長度檢查 (CVE-2023-53456)

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

    hsr修正 fill_frame_info() 中的 uninit-value 存取 (CVE-2023-53462)

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

    kobject針對 kset_register() 中的 kset->kobj.ktype 新增功能健全檢查 (CVE-2023-53480)

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

    iommu/amd/iommu_v2修正 pasid 解除系結上的 pasid_state refcount dec hit 0 警告 (CVE-2023-53501)

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

    PM / devfreq修正 devfreq_dev_release() 中的洩漏 (CVE-2023-53518)

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

    jbd2先檢查 'jh->b_transaction'然後再將其從檢查點移除 (CVE-2023-53526)

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

    null_blk修正輪詢要求逾時處理 (CVE-2023-53531)

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

    drm/i915標記 GuC 虛擬引擎的要求以避免釋放後使用 (CVE-2023-53552)

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

    bpf拒絕 bpf_sk_assign 中未雜湊的通訊端 (CVE-2023-53585)

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

    driversbase取消註冊裝置時釋放 devm 資源 (CVE-2023-53596)

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

    驅動程式hvvmbus不解除參照 ACPI root 物件處理 (CVE-2023-53647)

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

    perf 追踪實際釋放 evsel->priv 區域 (CVE-2023-53649)

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

    ext4修正 ext4_fname_{setup_filename,prepare_lookup} 中的記憶體洩漏 (CVE-2023-53662)

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

    KVMnSVM針對巢狀 TSC 縮放支援進行檢查而非宣告 (CVE-2023-53663)

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

    btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 (CVE-2023-53672)

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

    scsi目標iscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位 (CVE-2023-53676)

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

    NFS修正潛在的資料損毀 (CVE-2023-53711)

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

    mdraid1修正 raid1_remove_disk() 中潛在的 OOB (CVE-2023-53722)

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

    arm64csum針對負長度修正 IP 總和檢查碼程式碼中的 OoB 存取 (CVE-2023-53726)

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

    net/schedfq_pie避免 fq_pie_timer() 中的停止 (CVE-2023-53727)

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

    PCI釋放 coalescing 後釋放的資源 (CVE-2023-53743)

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

    net解決 kmalloc_reserve() 中的整數溢位 (CVE-2023-53752)

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

    cryptoapi - 使用 crypto_destroy_instance 中的工作佇列 (CVE-2023-53799)

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

    cryptolib/mpi - 避免 mpi_cmp_ui() 中發生 null 指標解除參照 (CVE-2023-53817)

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

    kcm修正 kcm_sendmsg() 中 SOCK_DGRAM 的錯誤處理。 (CVE-2023-53825)

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

    net在 sk_mc_loop() 中讀取 sk->sk_family 一次 (CVE-2023-53831)

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

    bpf、sockmap修正鎖定變更後的 skb refcnt 爭用 (CVE-2023-53836)

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

    md/raid5-cache修正 r5l_exit_log() 中的鎖死 (CVE-2023-53848)

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

    of重疊提前呼叫 of_changeset_init() (CVE-2023-53856)

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

    dm不嘗試在 RCU 保護下將 IO 排入佇列 (CVE-2023-53860)

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

    ext4更正 ext4_mb_good_group 中的 grp 驗證 (CVE-2023-53861)

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

    netipv4修正 __inet_del_ifa() 中的一個記憶體洩漏 (CVE-2023-53995)

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

    x86/sev使 enc_dec_hypercall() 接受一個大小而非 npages (CVE-2023-53996)

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

    af_unix修正有關 unix_tot_inflight 的資料爭用。 (CVE-2023-54006)

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

    audit修正 __audit_inode_child() 中可能的軟鎖定 (CVE-2023-54045)

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

    kcm修正 kcm_sendmsg() 錯誤路徑中的記憶體洩漏 (CVE-2023-54112)

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

    rcu安全地轉儲存 vmalloc 記憶體資訊 (CVE-2023-54113)

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

    s390/dcssblk修正因 list_add 損毀造成的核心損毀 (CVE-2023-54117)

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

    autofs修正 autofs_catatonic_mode 中的 waitqueue 記憶體洩漏 (CVE-2023-54134)

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

    vfio/type1修正 cap_migration 資訊洩漏 (CVE-2023-54137)

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

    scsi目標核心修正 target_cmd_counter 洩漏 (CVE-2023-54154)

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

    ofunittest修正 of_unittest_find_node_by_name() 中的 null 指標解除參照 (CVE-2023-54178)

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

    bpf修正驗證 allow_ptr_leaks 的問題 (CVE-2023-54181)

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

    btrfs修正 lockdep 展開以及執行延遲項目失敗後可能發生的鎖死 (CVE-2023-54224)

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

    ambabus修正 refcount 洩漏 (CVE-2023-54230)

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

    btrfs設定在 relocate_one_page 中 read_folio 之後映射的頁面範圍 (CVE-2023-54253)

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

    btrfs在 ino 查閱 ioctl 期間查閱 inode 之前釋放路徑 (CVE-2023-54281)

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

    KVMSVM從來源 VM 取得來源 vCPU以進行 SEV-ES 主機內移轉 (CVE-2023-54296)

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

    usbtypecbus驗證 typec_altmode_attention 中存在合作夥伴 (CVE-2023-54299)

    在密碼編譯演算法 scatterwalk 功能的 Linux 核心 API 中發現一個 null 指標解除參照缺陷。當使用者建構具有特定通訊端組態的惡意封包時，會發生此問題，其可允許本機使用者造成系統當機或提升其在系統上的權限。(CVE-2023-6176)

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

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

遠端主機上安裝的核心版本早於 5.4.257-170.359。因此，會受到 ALAS2KERNEL-5.4-2023-053 公告中所提及的多個弱點影響。

    在 Linux 核心用於轉換封包的 IP 架構 (XFRM 子系統) 中發現一個缺陷。此問題可允許具有 CAP_NET_ADMIN 權限的惡意使用者直接解除參照 xfrm_update_ae_params() 中的 NULL 指標，進而可能導致核心損毀和拒絕服務。(CVE-2023-3772)

    nf_osf_match_one() 中的 nftables 超出邊界讀取弱點 (CVE-2023-39189)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。xt_u32 模組未驗證 xt_u32 結構中的欄位。本機特權攻擊者可利用此缺陷，透過以陣列邊界外的值設定尺寸欄位來觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39192)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。sctp_mt_check 未驗證 flag_count 欄位。本機特權 (CAP_NET_ADMIN) 攻擊者可利用此缺陷觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39193)

    在 Linux 核心的 XFRM 子系統中發現一個缺陷。此特定缺陷存在於處理狀態篩選器的過程中，可導致讀取範圍超出配置緩衝區的結尾。本機特權 (CAP_NET_ADMIN) 攻擊者可利用此缺陷觸發超出邊界讀取，進而可能導致資訊洩漏。(CVE-2023-39194)

    上游認可對此問題的描述如下：

    ip_set_hash_netportnet 中遺漏的 IP_SET_HASH_WITH_NET0 巨集可導致程式使用錯誤的「CIDR_POS(c)」來計算陣列位移，進而導致整數反向溢位。因此，這會造成 slab 超出邊界存取。(CVE-2023-42753)

    在 rsvp_change() 中發現一個瑕疵。根本原因是 slab 超出邊界存取，但由於原始指標的位移是由使用者完全控制的 `unsign int`，因此該行為通常是環境指標存取。(CVE-2023-42755)

    在 6.5.3 之前版本的 Linux 核心中，發現 IGB 驅動程式中的 drivers/net/ethernet/intel/igb/igb_main.c 存在問題。緩衝區大小可能不足以容納大於 MTU 的框架。(CVE-2023-45871)

    Linux 核心的 af_unix 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    unix_stream_sendpage() 函式嘗試在未鎖定佇列的情況下，將資料新增至對等端 recv 佇列中的最後一個 skb。因此會發生爭用，unix_stream_sendpage() 可無鎖定存取由記憶體回收所釋放的 skb，進而導致釋放後使用。

    建議升級之前的 commit 790c2f9d15b594350ae9bca7b236f2b1859de02c。(CVE-2023-4622)

    Linux 核心的 net/sched: sch_hfsc (HFSC qdisc 流量控制) 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    如果具有連結共用曲線的類別 (即設定了 HFSC_FSC 旗標) 的父項沒有連結共用曲線，則 init_vf() 會呼叫父項上的 vttree_insert()，但會略過 update_vf( ) 上的 vttree_remove()。這會留下可造成釋放後使用的懸置指標。

    建議升級過去的 commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f。(CVE-2023-4623)

    Linux 核心的 net/sched: sch_qfq 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    當使用 plug qdisc 做為 qfq qdisc 的類別時，傳送網路封包會在 qfq_dequeue() 中觸發釋放後使用弱點，這是因為 sch_plug 的 .peek 處置程式不正確，且缺少 agg_dequeue() 中的錯誤檢查所致。

    建議升級過去的 commit 8fc134fee27f2263988ae38920bc03da416b03d8。(CVE-2023-4921)

    在 6.4.12 之前的 Linux 核心中，drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 的 amdgpu_cs_wait_all_fences 中存在隔離釋放後使用問題。(CVE-2023-51042)

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

    xfrm在 xfrm_update_ae_params 中新增 NULL 檢查 (CVE-2023-53147)

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

    udf修正部分路徑名稱的未初始化陣列存取 (CVE-2023-53165)

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

    netfilteripset新增 ip_set_hash_netportnet.c 遺漏的 IP_SET_HASH_WITH_NET0 巨集 (CVE-2023-53179)

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

    af_unix修正 user->unix_inflight 的資料爭用。 (CVE-2023-53204)

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

    drm/radeon修正 radeon_cs_parser_init 中的整數溢位 (CVE-2023-53309)

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

    drm/msm/mdp5不洩漏某些平面狀態 (CVE-2023-53324)

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

    pstore/ram檢查 init 期間空白 przs 的開始 (CVE-2023-53331)

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

    lwt修正 BPF xmit ops 的傳回值 (CVE-2023-53338)

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

    btrfs修正 btrfs_cancel_balance 中的 BUG_ON 條件 (CVE-2023-53339)

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

    skbuffskb_segment在使用 skbuff 片段之前呼叫零複製函式 (CVE-2023-53354)

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

    追踪修正 cpu 緩衝區寫入和交換之間的爭用問題 (CVE-2023-53368)

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

    ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至 Timer (CVE-2023-53395)

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

    HIDmultitouch更正 hidinput input_dev 名稱的 devm 裝置參照 (CVE-2023-53454)

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

    scsiqla4xxx新增剖析 nlattrs 時的長度檢查 (CVE-2023-53456)

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

    FSJFS修正 txBegin 中的 null-ptr-deref 讀取 (CVE-2023-53457)

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

    af_unix修正 unix_stream_sendpage() 中的 null-ptr-deref。 (CVE-2023-53469)

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

    kobject針對 kset_register() 中的 kset->kobj.ktype 新增功能健全檢查 (CVE-2023-53480)

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

    fsjfs修正 UBSAN array-index-out-of-bounds 在 dbAllocDmapLev 中 (CVE-2023-53485)

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

    powerpc/rtas_flash允許使用者復製到 flash 區塊快取物件 (CVE-2023-53487)

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

    xfrm修正 decode_session6 中的 slab 釋放後使用 (CVE-2023-53500)

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

    virtio-mmio不中斷 vm_dev 的生命週期 (CVE-2023-53515)

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

    PM / devfreq修正 devfreq_dev_release() 中的洩漏 (CVE-2023-53518)

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

    ip_vti修正 decode_session6 中潛在的 slab 釋放後使用 (CVE-2023-53559)

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

    cifs釋放命中 fscache 讀取時的作品集鎖定。 (CVE-2023-53593)

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

    ipmi_si修正 try_smi_init() 中的記憶體洩漏 (CVE-2023-53611)

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

    jfs修正 diUnmount 中 JFS_IP(ipimap)->i_imap 的無效釋放 (CVE-2023-53616)

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

    gfs2修正 gfs2_show_options() 中可能的資料爭用 (CVE-2023-53622)

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

    btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 (CVE-2023-53672)

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

    scsi目標iscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位 (CVE-2023-53676)

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

    mdraid1修正 raid1_remove_disk() 中潛在的 OOB (CVE-2023-53722)

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

    FSJFS檢查 txBegin 中掛載的唯讀檔案系統 (CVE-2023-53766)

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

    dccp修正 DCCP 錯誤處置程式中的超出邊界存取 (CVE-2023-53782)

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

    cryptolib/mpi - 避免 mpi_cmp_ui() 中發生 null 指標解除參照 (CVE-2023-53817)

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

    ip6_vti修正 decode_session6 中的 slab-use-after-free 問題 (CVE-2023-53821)

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

    kcm修正 kcm_sendmsg() 中 SOCK_DGRAM 的錯誤處理。 (CVE-2023-53825)

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

    net在 sk_mc_loop() 中讀取 sk->sk_family 一次 (CVE-2023-53831)

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

    netipv4修正 __inet_del_ifa() 中的一個記憶體洩漏 (CVE-2023-53995)

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

    af_unix修正有關 unix_tot_inflight 的資料爭用。 (CVE-2023-54006)

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

    audit修正 __audit_inode_child() 中可能的軟鎖定 (CVE-2023-54045)

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

    net不允許將 gso_size 設為 GSO_BY_FRAGS (CVE-2023-54051)

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

    kcm修正 kcm_sendmsg() 錯誤路徑中的記憶體洩漏 (CVE-2023-54112)

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

    fs/jfs防止 jfs_remount() 失敗後在 dbUnmount() 中發生重複釋放 (CVE-2023-54127)

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

    autofs修正 autofs_catatonic_mode 中的 waitqueue 記憶體洩漏 (CVE-2023-54134)

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

    nilfs2修正 mark_buffer_dirty 中因捨棄緩衝區重複使用而產生的警告 (CVE-2023-54140)

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

    quota修正 dqgrab() 中的警告 (CVE-2023-54177)

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

    ofunittest修正 of_unittest_find_node_by_name() 中的 null 指標解除參照 (CVE-2023-54178)

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

    還原 IB/isert修正錯誤的 isert 連線釋放 (CVE-2023-54219)

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

    serial8250修正 uart_change_pm() 上 port->pm 的 oops (CVE-2023-54220)

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

    ambabus修正 refcount 洩漏 (CVE-2023-54230)

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

    usbtypecbus驗證 typec_altmode_attention 中存在合作夥伴 (CVE-2023-54299)

    在密碼編譯演算法 scatterwalk 功能的 Linux 核心 API 中發現一個 null 指標解除參照缺陷。當使用者建構具有特定通訊端組態的惡意封包時，會發生此問題，其可允許本機使用者造成系統當機或提升其在系統上的權限。(CVE-2023-6176)

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

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

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

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq Commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic') will access 'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq().
    (CVE-2022-50329)

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10:
    ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace:
    bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
    __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
    __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90
    __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d (bfq: Split shared queues on move between cgroups) changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | | | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. (CVE-2022-50488)

  - 已解決 Linux 核心中的下列弱點：wifi: ath10k: Delay the unmapping of the buffer On WCN3990, we are seeing a rare scenario where copy engine hardware is sending a copy complete interrupt to the host driver while still processing the buffer that the driver has sent, this is leading into an SMMU fault triggering kernel panic. This is happening on copy engine channel 3 (CE3) where the driver normally enqueues WMI commands to the firmware. Upon receiving a copy complete interrupt, host driver will immediately unmap and frees the buffer presuming that hardware has processed the buffer. In the issue case, upon receiving copy complete interrupt, host driver will unmap and free the buffer but since hardware is still accessing the buffer (which in this case got unmapped in parallel), SMMU hardware will trigger an SMMU fault resulting in a kernel panic. In order to avoid this, as a work around, add a delay before unmapping the copy engine source DMA buffer. This is conditionally done for WCN3990 and only for the CE3 channel where issue is seen. Below is the crash signature: wifi smmu error: kernel: [10.120965] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fdfd8ac0, fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003, cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091: cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149 remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error <3> remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc pc :
    __arm_lpae_unmap+0x500/0x514 lr : __arm_lpae_unmap+0x4bc/0x514 sp : ffffffc011ffb530 x29: ffffffc011ffb590 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000004 x25: 0000000000000003 x24:
    ffffffc011ffb890 x23: ffffffa762ef9be0 x22: ffffffa77244ef00 x21: 0000000000000009 x20: 00000007fff7c000 x19: 0000000000000003 x18: 0000000000000000 x17: 0000000000000004 x16: ffffffd7a357d9f0 x15:
    0000000000000000 x14: 00fd5d4fa7ffffff x13: 000000000000000e x12: 0000000000000000 x11: 00000000ffffffff x10: 00000000fffffe00 x9 : 000000000000017c x8 : 000000000000000c x7 : 0000000000000000 x6 :
    ffffffa762ef9000 x5 : 0000000000000003 x4 : 0000000000000004 x3 : 0000000000001000 x2 : 00000007fff7c000 x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace: __arm_lpae_unmap+0x500/0x514
    __arm_lpae_unmap+0x4bc/0x514 __arm_lpae_unmap+0x4bc/0x514 arm_lpae_unmap_pages+0x78/0xa4 arm_smmu_unmap_pages+0x78/0x104 __iommu_unmap+0xc8/0x1e4 iommu_unmap_fast+0x38/0x48
    __iommu_dma_unmap+0x84/0x104 iommu_dma_free+0x34/0x50 dma_free_attrs+0xa4/0xd0 ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c [ath10k_core] ath10k_halt+0x11c/0x180 [ath10k_core] ath10k_stop+0x54/0x94 [ath10k_core] drv_stop+0x48/0x1c8 [mac80211] ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c [mac80211] __dev_open+0xb4/0x174
    __dev_change_flags+0xc4/0x1dc dev_change_flags+0x3c/0x7c devinet_ioctl+0x2b4/0x580 inet_ioctl+0xb0/0x1b4 sock_do_ioctl+0x4c/0x16c compat_ifreq_ioctl+0x1cc/0x35c compat_sock_ioctl+0x110/0x2ac
    __arm64_compat_sys_ioctl+0xf4/0x3e0 el0_svc_common+0xb4/0x17c el0_svc_compat_handler+0x2c/0x58 el0_svc_compat+0x8/0x2c Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 (CVE-2022-50700)

  - 已解決 Linux 核心中的下列弱點：tcp: fix a signed-integer-overflow bug in tcp_add_backlog() The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and in tcp_add_backlog(), the variable limit is caculated by adding sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value of int and overflow. This patch reduces the limit budget by halving the sndbuf to solve this issue since ACK packets are much smaller than the payload. (CVE-2022-50865)

  - 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bic_set_bfqq() After commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic'), bic->bfqq will be accessed in bic_set_bfqq(), however, in some context bic->bfqq will be freed, and bic_set_bfqq() is called with the freed bic->bfqq. Fix the problem by always freeing bfqq after bic_set_bfqq().
    (CVE-2023-52983)

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

CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1771078945 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已解決 Linux 核心中的下列弱點：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

CentOS Linux 8.5 主機安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1771077729 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已解決 Linux 核心中的下列弱點：be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

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

遠端主機上安裝的核心版本早於 5.10.197-186.748。因此，會受到 ALAS2KERNEL-510-2023-041 公告中所提及的多個弱點影響。

    在 rsvp_change() 中發現一個瑕疵。根本原因是 slab 超出邊界存取，但由於原始指標的位移是由使用者完全控制的 `unsign int`，因此該行為通常是環境指標存取。(CVE-2023-42755)

    Linux 核心的 netfilter: nf_tables 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    在相同交易的鏈結繫結中新增和移除規則會導致釋放後使用。

    建議升級過去的 Commit f15f29fd4779be8a418b66e9d52979bb6d6c2325。(CVE-2023-5197)

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

    ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至 Timer (CVE-2023-53395)

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

    kobject針對 kset_register() 中的 kset->kobj.ktype 新增功能健全檢查 (CVE-2023-53480)

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

    jfs修正 diUnmount 中 JFS_IP(ipimap)->i_imap 的無效釋放 (CVE-2023-53616)

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

    btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 (CVE-2023-53672)

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

    scsi目標iscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位 (CVE-2023-53676)

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

    mdraid1修正 raid1_remove_disk() 中潛在的 OOB (CVE-2023-53722)

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

    cryptolib/mpi - 避免 mpi_cmp_ui() 中發生 null 指標解除參照 (CVE-2023-53817)

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

    fs/jfs防止 jfs_remount() 失敗後在 dbUnmount() 中發生重複釋放 (CVE-2023-54127)

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

    autofs修正 autofs_catatonic_mode 中的 waitqueue 記憶體洩漏 (CVE-2023-54134)

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

    btrfs在 ino 查閱 ioctl 期間查閱 inode 之前釋放路徑 (CVE-2023-54281)

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

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

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

  - scsitargetiscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位。 lio_target_nacl_info_show() 函式在迴圈中使用 sprintf()來列印工作階段中每個 iSCSI 連線的詳細資料而不檢查緩衝區長度。在足夠 iSCSI 連線的情況下可能會造成 configfs 提供的緩衝區溢位並損毀記憶體。此修補程式以檢查緩衝區邊界的 sysfs_emit_at() 取代 sprintf()。 (CVE-2023-53676)

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

遠端主機上安裝的核心版本早於 4.14.326-245.539。因此，會受到 ALAS2-2023-2264 公告中所提及的多個弱點影響。

    在 Linux 核心用於轉換封包的 IP 架構 (XFRM 子系統) 中發現一個缺陷。此問題可允許具有 CAP_NET_ADMIN 權限的惡意使用者直接解除參照 xfrm_update_ae_params() 中的 NULL 指標，進而可能導致核心損毀和拒絕服務。(CVE-2023-3772)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。xt_u32 模組未驗證 xt_u32 結構中的欄位。本機特權攻擊者可利用此缺陷，透過以陣列邊界外的值設定尺寸欄位來觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39192)

    在 Linux 核心的 Netfilter 子系統中發現一個缺陷。sctp_mt_check 未驗證 flag_count 欄位。本機特權 (CAP_NET_ADMIN) 攻擊者可利用此缺陷觸發超出邊界讀取，進而導致當機或資訊洩漏。(CVE-2023-39193)

    在 Linux 核心的 XFRM 子系統中發現一個缺陷。此特定缺陷存在於處理狀態篩選器的過程中，可導致讀取範圍超出配置緩衝區的結尾。本機特權 (CAP_NET_ADMIN) 攻擊者可利用此缺陷觸發超出邊界讀取，進而可能導致資訊洩漏。(CVE-2023-39194)

    Linux 核心的 net/sched: cls_fw 元件中有一個釋放後使用弱點，可遭惡意利用來提升本機權限。

    在現有篩選器上呼叫 fw_change() 時，一律會將整個 tcf_result 結構複製到篩選器的新執行個體中。這會在將篩選器限制更新至類別時造成問題，因為一律在成功路徑中的舊執行個體上呼叫 tcf_unbind_filter() 會減少仍參照之類別的 filter_cnt 並允許將其刪除，進而造成釋放後使用。

    建議升級之前的 commit 76e42ae831991c828cffa8c37736ebfb831ad5ec。(CVE-2023-4207)

    Linux 核心的 netfilter: nf_tables 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    nf_tables netlink 控制平面交易和 nft_set 元素記憶體回收之間存在爭用情形，可能會使參照計數器反向溢位，進而造成釋放後使用弱點。

    建議升級過去的 Commit 3e91b0ebd994635df2346353322ac51ce84ce6d8。(CVE-2023-4244)

    上游認可對此問題的描述如下：

    ip_set_hash_netportnet 中遺漏的 IP_SET_HASH_WITH_NET0 巨集可導致程式使用錯誤的「CIDR_POS(c)」來計算陣列位移，進而導致整數反向溢位。因此，這會造成 slab 超出邊界存取。(CVE-2023-42753)

    在 rsvp_change() 中發現一個瑕疵。根本原因是 slab 超出邊界存取，但由於原始指標的位移是由使用者完全控制的 `unsign int`，因此該行為通常是環境指標存取。(CVE-2023-42755)

    在 6.5.3 之前版本的 Linux 核心中，發現 IGB 驅動程式中的 drivers/net/ethernet/intel/igb/igb_main.c 存在問題。緩衝區大小可能不足以容納大於 MTU 的框架。(CVE-2023-45871)

    Linux 核心的 af_unix 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    unix_stream_sendpage() 函式嘗試在未鎖定佇列的情況下，將資料新增至對等端 recv 佇列中的最後一個 skb。因此會發生爭用，unix_stream_sendpage() 可無鎖定存取由記憶體回收所釋放的 skb，進而導致釋放後使用。

    建議升級之前的 commit 790c2f9d15b594350ae9bca7b236f2b1859de02c。(CVE-2023-4622)

    Linux 核心的 net/sched: sch_hfsc (HFSC qdisc 流量控制) 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    如果具有連結共用曲線的類別 (即設定了 HFSC_FSC 旗標) 的父項沒有連結共用曲線，則 init_vf() 會呼叫父項上的 vttree_insert()，但會略過 update_vf( ) 上的 vttree_remove()。這會留下可造成釋放後使用的懸置指標。

    建議升級過去的 commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f。(CVE-2023-4623)

    Linux 核心的 net/sched: sch_qfq 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    當使用 plug qdisc 做為 qfq qdisc 的類別時，傳送網路封包會在 qfq_dequeue() 中觸發釋放後使用弱點，這是因為 sch_plug 的 .peek 處置程式不正確，且缺少 agg_dequeue() 中的錯誤檢查所致。

    建議升級過去的 commit 8fc134fee27f2263988ae38920bc03da416b03d8。(CVE-2023-4921)

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

    xfrm在 xfrm_update_ae_params 中新增 NULL 檢查 (CVE-2023-53147)

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

    udf修正部分路徑名稱的未初始化陣列存取 (CVE-2023-53165)

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

    scsi核心修正 device_add() 失敗時可能發生的記憶體洩漏 (CVE-2023-53174)

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

    netfilteripset新增 ip_set_hash_netportnet.c 遺漏的 IP_SET_HASH_WITH_NET0 巨集 (CVE-2023-53179)

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

    af_unix修正 user->unix_inflight 的資料爭用。 (CVE-2023-53204)

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

    scsistorvsc修正虛擬光纖通道逾時的處理 (CVE-2023-53245)

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

    drm/radeon修正 radeon_cs_parser_init 中的整數溢位 (CVE-2023-53309)

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

    nilfs2修正透過 iput 污染 inode 時nilfs_root 的釋放後使用 (CVE-2023-53311)

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

    pstore/ram檢查 init 期間空白 przs 的開始 (CVE-2023-53331)

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

    ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至 Timer (CVE-2023-53395)

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

    HIDmultitouch更正 hidinput input_dev 名稱的 devm 裝置參照 (CVE-2023-53454)

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

    scsiqla4xxx新增剖析 nlattrs 時的長度檢查 (CVE-2023-53456)

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

    FSJFS修正 txBegin 中的 null-ptr-deref 讀取 (CVE-2023-53457)

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

    af_unix修正 unix_stream_sendpage() 中的 null-ptr-deref。 (CVE-2023-53469)

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

    kobject針對 kset_register() 中的 kset->kobj.ktype 新增功能健全檢查 (CVE-2023-53480)

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

    fsjfs修正 UBSAN array-index-out-of-bounds 在 dbAllocDmapLev 中 (CVE-2023-53485)

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

    PM / devfreq修正 devfreq_dev_release() 中的洩漏 (CVE-2023-53518)

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

    ip_vti修正 decode_session6 中潛在的 slab 釋放後使用 (CVE-2023-53559)

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

    cifs釋放命中 fscache 讀取時的作品集鎖定。 (CVE-2023-53593)

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

    jfs修正 diUnmount 中 JFS_IP(ipimap)->i_imap 的無效釋放 (CVE-2023-53616)

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

    gfs2修正 gfs2_show_options() 中可能的資料爭用 (CVE-2023-53622)

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

    btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 (CVE-2023-53672)

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

    scsi目標iscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位 (CVE-2023-53676)

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

    mdraid1修正 raid1_remove_disk() 中潛在的 OOB (CVE-2023-53722)

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

    FSJFS檢查 txBegin 中掛載的唯讀檔案系統 (CVE-2023-53766)

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

    dccp修正 DCCP 錯誤處置程式中的超出邊界存取 (CVE-2023-53782)

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

    cryptolib/mpi - 避免 mpi_cmp_ui() 中發生 null 指標解除參照 (CVE-2023-53817)

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

    ip6_vti修正 decode_session6 中的 slab-use-after-free 問題 (CVE-2023-53821)

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

    kcm修正 kcm_sendmsg() 中 SOCK_DGRAM 的錯誤處理。 (CVE-2023-53825)

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

    net在 sk_mc_loop() 中讀取 sk->sk_family 一次 (CVE-2023-53831)

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

    dccp修正有關 dp->dccps_mss_cache 的資料爭用 (CVE-2023-53839)

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

    usb-storagealauda修正 alauda_check_media() 中的 uninit-value (CVE-2023-53847)

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

    af_unix修正有關 unix_tot_inflight 的資料爭用。 (CVE-2023-54006)

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

    audit修正 __audit_inode_child() 中可能的軟鎖定 (CVE-2023-54045)

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

    net不允許將 gso_size 設為 GSO_BY_FRAGS (CVE-2023-54051)

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

    kcm修正 kcm_sendmsg() 錯誤路徑中的記憶體洩漏 (CVE-2023-54112)

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

    fs/jfs防止 jfs_remount() 失敗後在 dbUnmount() 中發生重複釋放 (CVE-2023-54127)

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

    autofs修正 autofs_catatonic_mode 中的 waitqueue 記憶體洩漏 (CVE-2023-54134)

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

    nilfs2修正 mark_buffer_dirty 中因捨棄緩衝區重複使用而產生的警告 (CVE-2023-54140)

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

    quota修正 dqgrab() 中的警告 (CVE-2023-54177)

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

    ofunittest修正 of_unittest_find_node_by_name() 中的 null 指標解除參照 (CVE-2023-54178)

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

    還原 IB/isert修正錯誤的 isert 連線釋放 (CVE-2023-54219)

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

    serial8250修正 uart_change_pm() 上 port->pm 的 oops (CVE-2023-54220)

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

    ambabus修正 refcount 洩漏 (CVE-2023-54230)

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

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

CentOS Linux 7 主機已安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1782148320 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - 已解決 Linux 核心中的下列弱點：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

  - 已解決 Linux 核心中的下列弱點：scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. (CVE-2022-48791)

  - 已解決 Linux 核心中的下列弱點：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已解決 Linux 核心中的下列弱點：dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
182458	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-356)	Nessus	Amazon Linux Local Security Checks	2023/10/3	2026/2/12	high
182660	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。4-2023-053 (ALASKERNEL-5.4-2023-053)	Nessus	Amazon Linux Local Security Checks	2023/10/6	2026/2/11	high
360081	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1771239384）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
361173	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.4：CLSA-2026：1771078945）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
360928	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點（CENTOS8.5：CLSA-2026：1771077729）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
183265	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2023-041 (ALASKERNEL-5.10-2023-041)	Nessus	Amazon Linux Local Security Checks	2023/10/18	2026/2/9	high
270185	Linux Distros 未修補的弱點：CVE-2023-53676	Nessus	Misc.	2025/10/13	2026/9/30	high
182628	Amazon Linux 2核心 --advisory ALAS2-2023-2264 (ALAS-2023-2264)	Nessus	Amazon Linux Local Security Checks	2023/10/5	2026/2/11	high
353232	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high

high