遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2026:77216 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：ALSA：firewire-motu：修正 DSP 事件的 hwdep 讀取中的緩衝區溢位弱點 (CVE-2025-68347)

    * 核心：xfrm：保留 dev ref 直到 transport_finish NF_HOOK 之後 (CVE-2026-31663)

    * 核心：udf：修正分割區描述元附加簿記 (CVE-2026-45991)

    * 核心：RDMA/rxe：在 rxe_rcv 中的 payload_size() 之前驗證 pad 和 ICRC (CVE-2026-46043)

    * 核心：RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 (CVE-2026-46133)

    * kernel：ipc：將 next_id 分配限制為有效 ID 範圍 (CVE-2026-52923)

    * 核心：sctp：在過時的 COOKIE-ECHO 處理上清除輸出佇列 (CVE-2026-52924)

    * 核心：dm 快取原則 smq：修正無效快取區塊中缺少的鎖定 (CVE-2026-53062)

    * 核心：xfrm：policy：修正 xfrm_policy_bysel_ctx() 中有關 inexact bin 的釋放後使用 (CVE-2026-53239)

    * 核心：netfilter：synproxy：skb_ensure_writable 後重新整理 tcphdr (CVE-2026-64007)

    * 核心：ip6：vti：在 vti6_siocdevprivate() 中使用 ip6_tnl.net (CVE-2026-63921)

    * 核心：xfrm：input：在延遲傳輸重新注入期間保留 netns (CVE-2026-63919)

    * 核心：ip6：vti：在 vti6_changelink() 中使用 ip6_tnl.net (CVE-2026-63917)

    * 核心：nvmet：修正探索取得記錄頁面中的預先驗證越界堆積讀取 (CVE-2026-64320)

    * 核心：AMD-SN-7061：安全 RET 中斷弱點 (CVE-2026-68480)

    * 核心：RDMA/rxe：修正 rxe_mmap 中的釋放後使用問題 (CVE-2026-64582)

    * 核心：net：qrtr：將通訊端建立限制為初始網路命名空間 (CVE-2026-68294)

    * 核心：xfrm：在非同步加密竊取 GSO 區段後修正過時的 skb->prev (CVE-2026-68426)

    * 核心：scsi：libiscsi_tcp：將 SCSI 回應資料區段繫結至連線緩衝區 (CVE-2026-74556)

    * 核心：netfilter：flowtable：最後發布 GC 可見元組 (CVE-2026-74746)

    * 核心：RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的回應程式 UAF (CVE-2026-80864)

    * 核心：RDMA/rxe：修正 free_rd_atomic_resources() 中的 OOB (CVE-2026-80863)

    錯誤修正和增強功能：

    * 傳回委派時 NFS 用戶端停擺 (JIRA：RHEL-112278)

    * scsi：mpt3sas：避免釋放未分配的 PCIe SGL 緩衝區 (JIRA：RHEL-256998)

    * inode 分配期間 [xfs_trans_cancel] 的 xfs 損毀 (JIRA：RHEL-257186)

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2026:77301 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：smc：修正 tcp_write_timer_handler（） 中的釋放後使用 （CVE-2023-53781）

    * 核心：ALSA：firewire-motu：修正 DSP 事件的 hwdep 讀取中的緩衝區溢位弱點 (CVE-2025-68347)

    * 核心：xfrm：保留 dev ref 直到 transport_finish NF_HOOK 之後 (CVE-2026-31663)

    * 核心：藍牙：MGMT：載入時驗證 LTK enc_size (CVE-2026-43020)

    * 核心： Linux 核心：xfrm 單片段長度未正確限制 （）

    * 核心：RDMA/rxe：在 rxe_rcv 中的 payload_size() 之前驗證 pad 和 ICRC (CVE-2026-46043)

    * 核心：RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 (CVE-2026-46133)

    * 核心：sctp：在過時的 COOKIE-ECHO 處理上清除輸出佇列 (CVE-2026-52924)

    * 核心：xfrm：policy：修正 xfrm_policy_bysel_ctx() 中有關 inexact bin 的釋放後使用 (CVE-2026-53239)

    * 核心：ip6：vti：在 vti6_siocdevprivate() 中使用 ip6_tnl.net (CVE-2026-63921)

    * 核心：xfrm：input：在延遲傳輸重新注入期間保留 netns (CVE-2026-63919)

    * 核心：ip6：vti：在 vti6_changelink() 中使用 ip6_tnl.net (CVE-2026-63917)

    * 核心：AMD-SN-7061：安全 RET 中斷弱點 (CVE-2026-68480)

    * 核心：RDMA/rxe：修正 rxe_mmap 中的釋放後使用問題 (CVE-2026-64582)

    * 核心：net：qrtr：將通訊端建立限制為初始網路命名空間 (CVE-2026-68294)

    * 核心：xfrm：在非同步加密竊取 GSO 區段後修正過時的 skb->prev (CVE-2026-68426)

    * 核心：netfilter： flowtable：最後發布 GC 可見元組 （CVE-2026-74746）

    * 核心：RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的回應程式 UAF （CVE-2026-80864）

    * 核心：RDMA/rxe：修正 free_rd_atomic_resources（）CVE-2026-80863 （） 中的 OOB

    錯誤修正和增強功能：

    * scsi：mpt3sas：避免釋放未分配的 PCIe SGL 緩衝區 （JIRA：RHEL-256999）

    * inode 分配期間 [xfs_trans_cancel] 的 xfs 損毀 （JIRA：RHEL-257187）

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

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

  - RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr（） 上的回應程式 UAF 會處理IB_QP_STATE路徑之外的IB_QP_MAX_DEST_RD_ATOMIC，因此它不會保留任何state_lock，並在回應程式工作 rxe_receiver（） （rxe_wq 上的 recv_task） 作用中時執行。僅該屬性的 modify_qp（） 設定呼叫 free_rd_atomic_resources（），然後呼叫 alloc_rd_atomic_resources（），在 rxe_prepare_res（）/find_resource（） 遍歷時交換 qp->resp.resources[];free_rd_atomic_resources（） 也會讓快取的指標 qp->resp.res 懸空。本機非特權使用者可以在 rxe_receiver（） 中將 free/realloc 爭用為釋放後使用（本機 DoS）。使用 rxe_disable_task（）/rxe_enable_task（） 在交換周圍清空recv_task，就像 rxe_qp_reset（） 在拆除此陣列時所做的那樣，只有在 alloc_rd_atomic_resources（） 成功後才重新啟用，這樣回應程式就永遠不會針對 ENOMEM 路徑上的 NULL qp->resp.resources 繼續。同時清除 free_rd_atomic_resources（） 中的 qp->resp.res，例如 rxe_resp.c 完成路徑。在 KASAN 下複製;rxe_receiver（） 中的 slab-use-after-free 消失了。（CVE-2026-80864）

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

遠端 Redhat Enterprise Linux 9 主機上安裝的多個套件受到 RHSA-2026:77218 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：xfrm：保留 dev ref 直到 transport_finish NF_HOOK 之後 (CVE-2026-31663)

    * kernel: smb: client：修正剖析符號連結錯誤回應時的超出邊界讀取弱點 (CVE-2026-31613)

    * 核心：RDMA/rxe：修正 QP 計時器處理常式中的爭用情形 (CVE-2026-45910)

    * 核心：RDMA/rxe：在 rxe_rcv 中的 payload_size() 之前驗證 pad 和 ICRC (CVE-2026-46043)

    * 核心：RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 (CVE-2026-46133)

    * 核心：RDMA/rxe：拒絕非 8 位元組 ATOMIC_WRITE 承載 (CVE-2026-46114)

    * 核心：xfrm：policy：修正 xfrm_policy_bysel_ctx() 中有關 inexact bin 的釋放後使用 (CVE-2026-53239)

    * 核心：ipv6：exthdrs：在 ipv6_hop_jumbo() 之後重新整理 nh 指標 (CVE-2026-63924)

    * 核心：ipv6：exthdrs：處理 HAO 選項後重新整理 nh (CVE-2026-63922)

    * 核心：ipv6：在複製到 cmsg 前，先驗證延伸標頭長度 (CVE-2026-63920)

    * 核心：netfilter：synproxy：skb_ensure_writable 後重新整理 tcphdr (CVE-2026-64007)

    * 核心：ip6：vti：在 vti6_siocdevprivate() 中使用 ip6_tnl.net (CVE-2026-63921)

    * 核心：ipv6：rpl：修正 ipv6_rpl_srh_decompress() 中的 hdrlen 溢位問題 (CVE-2026-63984)

    * 核心：xfrm：input：在延遲傳輸重新注入期間保留 netns (CVE-2026-63919)

    * 核心：ip6：vti：在 vti6_changelink() 中使用 ip6_tnl.net (CVE-2026-63917)

    * 核心：RDMA/rxe：修正 rxe_mmap 中的釋放後使用問題 (CVE-2026-64582)

    * 核心：xfrm：在非同步加密竊取 GSO 區段後修正過時的 skb->prev (CVE-2026-68426)

    * kernel: nvmet-auth：拒絕短 AUTH_RECEIVE 緩衝區 (CVE-2026-72130)

    * 核心：ipv6：修正 ip6_finish_output2() 中的釋放後使用問題 (CVE-2026-80792)

    * 核心：RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的回應程式 UAF (CVE-2026-80864)

    * 核心：RDMA/rxe：修正 free_rd_atomic_resources() 中的 OOB (CVE-2026-80863)

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2026:77217 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：xfrm：保留 dev ref 直到 transport_finish NF_HOOK 之後 (CVE-2026-31663)

    * 核心：ALSA：6fire：修正斷開連接時的釋放後使用 （CVE-2026-31581）

    * 核心：gfs2：修正 iomap 內嵌資料寫入路徑 (CVE-2026-45984) 中的釋放後使用

    * 核心：udf：修正分割區描述元附加簿記 (CVE-2026-45991)

    * 核心：RDMA/rxe：在 rxe_rcv 中的 payload_size() 之前驗證 pad 和 ICRC (CVE-2026-46043)

    * 核心：RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 (CVE-2026-46133)

    * 核心：sctp：在過時的 COOKIE-ECHO 處理上清除輸出佇列 (CVE-2026-52924)

    * 核心：xfrm：policy：修正 xfrm_policy_bysel_ctx() 中有關 inexact bin 的釋放後使用 (CVE-2026-53239)

    * 核心：netfilter：synproxy：skb_ensure_writable 後重新整理 tcphdr (CVE-2026-64007)

    * 核心：ip6：vti：在 vti6_siocdevprivate() 中使用 ip6_tnl.net (CVE-2026-63921)

    * 核心：xfrm：input：在延遲傳輸重新注入期間保留 netns (CVE-2026-63919)

    * 核心：ip6：vti：在 vti6_changelink() 中使用 ip6_tnl.net (CVE-2026-63917)

    * 核心：RDMA/rxe：修正 rxe_mmap 中的釋放後使用問題 (CVE-2026-64582)

    * 核心：net：qrtr：將通訊端建立限制為初始網路命名空間 (CVE-2026-68294)

    * 核心：xfrm：在非同步加密竊取 GSO 區段後修正過時的 skb->prev (CVE-2026-68426)

    * 核心：scsi：libiscsi_tcp：將 SCSI 回應資料區段繫結至連線緩衝區 (CVE-2026-74556)

    * 核心：netfilter： flowtable：最後發布 GC 可見元組 （CVE-2026-74746）

    * 核心：RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的回應程式 UAF （CVE-2026-80864）

    * 核心：RDMA/rxe：修正 free_rd_atomic_resources（）CVE-2026-80863 （） 中的 OOB

    錯誤修正和增強功能：

    * inode 分配期間 [xfs_trans_cancel] 的 xfs 損毀 （JIRA：RHEL-257185）

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

遠端 CentOS Linux 9 主機上安裝的套件受到 kernel-5.14.0-756.el9 版本變更記錄中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element.
    _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN. (CVE-2026-68402)

  - 已解決 Linux 核心中的下列弱點：RDMA/siw: Reject MPA FPDU length underflow before signed receive math A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace:
    skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 (Marker and ULPDU Length fields do not agree on the start of an FPDU), the correct framing-error class for this inconsistency.
    (CVE-2026-64102)

  - 已解決 Linux 核心中的下列弱點：RDMA/rxe: Fix race condition in QP timer handlers I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU:
    0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING:
    drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ...
    WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3:
    kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() {spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use. (CVE-2026-45910)

  - 已解決 Linux 核心中的下列弱點：ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads.
    Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy
    __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:
    ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. (CVE-2026-45942)

  - 已解決 Linux 核心中的下列弱點：RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE. (CVE-2026-46043)

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

遠端 Redhat Enterprise Linux 9 主機上安裝的多個套件受到 RHSA-2026:77219 公告中提及的多個弱點影響。

    核心套件中包含 Linux 核心，後者是任何 Linux 作業系統的核心。

    安全性修正：

    * 核心：ipv6：在 SRv6 路徑中新增對 idev 的 NULL 檢查 （CVE-2026-23442）

    * 核心：RDMA/rxe：修正 QP 計時器處理常式中的爭用情形 (CVE-2026-45910)

    * 核心：RDMA/rxe：在 rxe_rcv 中的 payload_size() 之前驗證 pad 和 ICRC (CVE-2026-46043)

    * 核心：RDMA/rxe：在 ICRC 處理之前拒絕未知的操作碼 (CVE-2026-46133)

    * 核心：RDMA/rxe：拒絕非 8 位元組 ATOMIC_WRITE 承載 (CVE-2026-46114)

    * 核心：ipv6： exthdrs：在 ipv6_hop_jumbo（） （CVE-2026-63924） 之後重新整理 NH 指標

    * 核心：ipv6： exthdrs：處理 HAO 選項 （CVE-2026-63922） 後重新整理 NH

    * 核心：ipv6：在複製到 cmsg （CVE-2026-63920） 之前驗證擴充標頭長度

    * 核心：ipv6： rpl：修正 ipv6_rpl_srh_decompress（） 中的 hdrlen 溢位 （CVE-2026-63984）

    * 核心：核心 SMB 用戶端：雙重釋放弱點允許遠端拒絕服務或權限提升 （CVE-2026-64385）

    * 核心：smb：client：修正 SMB2_flush() 重播中的雙重釋放 (CVE-2026-64383)

    * 核心：smb：client：修正 query_info() 重播雙重釋放 (CVE-2026-64386)

    * 核心：RDMA/rxe：修正 rxe_mmap 中的釋放後使用問題 (CVE-2026-64582)

    * 核心：ipv6：修正 ip6_finish_output2（） 中的釋放後使用 （CVE-2026-80792）

    * 核心：RDMA/rxe：修正 IB_QP_MAX_DEST_RD_ATOMIC modify_qp 上的回應程式 UAF （CVE-2026-80864）

    * 核心：RDMA/rxe：修正 free_rd_atomic_resources（）CVE-2026-80863 （） 中的 OOB

    錯誤修正和增強功能：

    * gfs2：遠端刪除問題 [rhel-9.6.z] （JIRA：RHEL-172430）

    如需安全性問題的詳細資料，包括影響、CVSS 評分、致謝及其他相關資訊，請參閱〈參照〉一節列出的 CVE 頁面。

Tenable 已直接從 Red Hat Enterprise Linux 安全公告擷取前置描述區塊。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
363766	RHEL 8：核心 (RHSA-2026:77216)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	critical
363823	RHEL 8：核心 (RHSA-2026:77301)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	high
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 核心 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
343044	Linux Distros 未修補弱點：CVE-2026-80864	Nessus	Misc.	2026/9/4	2026/11/6	high
363822	RHEL 9：核心 (RHSA-2026:77218)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	critical
363817	RHEL 8：核心 (RHSA-2026:77217)	Nessus	Red Hat Local Security Checks	2026/10/7	2026/10/21	high
363461	CentOS 9：kernel-5.14.0-756.el9	Nessus	CentOS Local Security Checks	2026/10/6	2026/10/26	critical
362907	Debian dla-4817 ： ata-modules-6.12.107+deb12-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
351155	Debian dsa-6528 ： ata-modules-6.12.111+deb13-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
364148	RHEL 9：核心 (RHSA-2026:77219)	Nessus	Red Hat Local Security Checks	2026/10/8	2026/10/21	medium

偵測

搜尋 Plugin

critical

high

high

high

critical

high

critical

high

high

medium