遠端 Ubuntu 22.04 LTS/24.04 LTS 主機上安裝的一個套件受到 USN-8497-1 公告中所提及的多個弱點影響。

    據發現，Linux 核心在通訊端緩衝區操作期間未正確處理共用頁面片段，統稱為 Dirty Frag。處理分頁片段時，XFRM ESP-in-TCP 子系統和 RxRPC 網路子系統中存在邏輯缺陷。本機攻擊者可能會利用此問題提升特權，或者可能造成容器逸出。(CVE-2026-43284、CVE-2026-43500、CVE-2026-45998、CVE-2026-46000)

    據發現，在處理通訊端緩衝區片段時，Linux 核心的 XFRM ESP-in-TCP 子系統存在邏輯缺陷。此缺陷又稱為 Fragnesia。本機攻擊者可能會利用此問題提升特權，或者可能造成容器逸出。(CVE-2026-43503、CVE-2026-46300)

    Qualys 發現，在退出有特權的處理程序時，Linux 核心的 ptrace 子系統中存在爭用情形。非特權本機攻擊者可利用此問題洩漏敏感資訊。(CVE-2026-46333)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含記憶體流失弱點。本機攻擊者可對此加以利用，從而造成資源耗盡。(CVE-2026-47326)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含 NULL 指標解除參照。本機攻擊者可惡意利用此問題導致核心 oops。
    (CVE-2026-47327)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含無效釋放弱點。本機攻擊者可惡意利用此問題導致核心記憶體損毀。
    (CVE-2026-47328)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 存在未充分驗證 AppArmor 通知回應弱點。本機攻擊者可利用此函式來處理特製的回應。(CVE-2026-47329)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含未初始化的變數。本機攻擊者可利用此問題造成資料快取不正確。
    (CVE-2026-47330)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8 包含釋放後使用 (UAF) 錯誤。本機攻擊者可利用此錯誤造成記憶體損毀，理論上會導致任意程式碼執行。
    (CVE-2026-47331)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含超出邊界 (OOB) 讀取弱點。本機攻擊者可利用此弱點披露內核內存的資訊。(CVE-2026-47332)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含超出邊界 (OOB) 讀取弱點。本機攻擊者可利用此弱點造成核心記憶體損毀，這在理論上會影響 AppArmor 原則的處理。(CVE-2026-47333)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 通知時包含不正確的保留鎖定。本機攻擊者可惡意利用此問題導致核心錯誤或鎖死。
    (CVE-2026-47334)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8 在處理 AppArmor 通知時包含 NULL 指標解除參照。本機攻擊者可惡意利用此問題導致核心錯誤。(CVE-2026-47335)

    Tristan Madani 發現，Ubuntu Linux 核心 6.8 在處理 AppArmor AF_INET/AF_INET6 通訊端中介時包含未初始化的變數。本機攻擊者可利用此問題來影響精細網路通訊端中介的處理方式。(CVE-2026-47336)

    Tristan Madani 和 Trevor Lawrence 各自發現，Ubuntu Linux 核心 6.8、6.17 和 7.0 在處理 AppArmor 網路通訊端中介時包含 NULL 指標解除參照。本機攻擊者可惡意利用此問題導致核心 oops。(CVE-2026-47337)

    在 Linux 核心中發現數個安全性問題。攻擊者可能會利用這些弱點入侵系統。此更新可更正下列子系統中的瑕疵：

    - ARM64 架構；

    - MIPS 架構；

    - PowerPC 架構；

    - x86 架構；

    - 區塊層子系統；

    - 密碼編譯 API;

    - ACPI 驅動程式；

    - ATM 驅動程式 ;

    - RNBD 區塊裝置驅動程式;

    - Ublk 使用者空間區塊驅動程式；

    - 匯流排裝置；

    - 字元裝置驅動程式 ;

    - TPM 裝置驅動程式；

    - 時鐘架構和驅動程式 ;

    - Clocksource 驅動程式;

    - CPU閒置管理框架;

    - 硬體加密裝置驅動程式；

    - DMA 引擎子系統;

    - EFI 核心;

    - GPIO 子系統；

    - GPU 驅動程式；

    - HID 子系統 ;

    - 硬體監控驅動程式;

    - IIO 子系統；

    - InfiniBand 驅動程式；

    - IOMMU 子系統；

    - 多個裝置驅動程式；

    - 媒體驅動程式；

    - 多功能裝置驅動程式；

    - Broadcom VK 加速器驅動程序;

    - MOST (媒體導向系統傳輸) 驅動程式；

    - MTD 區塊裝置驅動程式；

    - 乙太網路綁定驅動程式 ;

    - 網路驅動程式;

    - Mellanox 網路驅動程式；

    - STMicroelectronics 網路驅動程式；

    - NTB 驅動程式；

    - NVME 驅動程式；

    - PCI 子系統；

    - 效能監控驅動程式；

    - 針腳控制器子系統；

    - x86 平台驅動程式；

    - 電源驅動程式;

    - RapidIO 驅動程式;

    - RAS（可靠性、可用性、可維護性）子系統;

    - Remote Processor 子系統;

    - RPMSG 子系統；

    - S/390 驅動程式 ;

    - SCSI 子系統；

    - 聯發科 SoC 驅動程式;

    - Texas Instruments SoC  驅動程式；

    - SPI 子系統；

    - Greybus lights staging 驅動程式；

    - Realtek RTL8723BS SDIO 驅動程式；

    - UFS 子系統;

    - ChipIdea USB 驅動程式;

    - DesignWare USB3 驅動程式；

    - USB over IP 驅動程式 ;

    - vDPA 驅動程式;

    - Virtio Host (VHOST) 子系統;

    - Framebuffer 層；

    - BTRFS 檔案系統；

    - 檔案系統基礎架構;

    - Ceph 分散式檔案系統;

    - Ext4 檔案系統；

    - F2FS 檔案系統；

    - FAT 檔案系統；

    - GFS2 檔案系統；

    - HFS+ 檔案系統；

    - JFS 檔案系統；

    - 網路檔案系統 (NFS) 伺服器程序；

    - NILFS2 檔案系統；

    - NTFS3 檔案系統；

    - OCFS2 檔案系統；

    - Proc 檔案系統；

    - Pstore 檔案系統；

    - Diskquota 系統；

    - SMB 網路檔案系統；

    - XFS 檔案系統；

    - 稽核子系統;

    - 記憶體管理 ;

    - IPv6 網路；

    - Netfilter；

    - 追蹤基礎架構；

    - 核心：kexec（） syscall;

    - RCU 子系統；

    - 排程器基礎架構；

    - 散點清單 API;

    - 9P 檔案系統網路通訊協定；

    - 非同步傳輸模式 (ATM) 子系統；

    - B.A.T.M.A.N. 網狀通訊協定；

    - 藍牙子系統；

    - 乙太網路橋接器；

    - Ceph Core 程式庫；

    - 網路核心；

    - IPv4 網路；

    - KCM (核心連線多工器) 通訊端驅動程式 ;

    - 多重路徑 TCP;

    - NFC 子系統；

    - RDS 通訊協定;

    - RxRPC 工作階段通訊端；

    - 網路流量控制；

    - SMC 通訊端；

    - Sun RPC 通訊協定；

    - X.25網路層;

    - XFRM 子系統；

    - AppArmor 安全性模組 ;

    - 簡化強制存取控制核心架構 ;

    - SOF 驅動程式；

    - USB 聲音裝置； (CVE-2025-40005, CVE-2025-71229, CVE-2025-71231, CVE-2025-71232, CVE-2025-71233, CVE-2025-71235, CVE-2025-71236, CVE-2025-71237, CVE-2025-71238, CVE-2025-71239, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2025-71272, CVE-2025-71273, CVE-2025-71274, CVE-2025-71286, CVE-2025-71291, CVE-2025-71292, CVE-2025-71294, CVE-2025-71295, CVE-2025-71297, CVE-2025-71304, CVE-2025-71305, CVE-2026-23100, CVE-2026-23169, CVE-2026-23220, CVE-2026-23221, CVE-2026-23222, CVE-2026-23228, CVE-2026-23229, CVE-2026-23230, CVE-2026-23233, CVE-2026-23234, CVE-2026-23235, CVE-2026-23236, CVE-2026-23237, CVE-2026-23238, CVE-2026-23241, CVE-2026-23242, CVE-2026-23243, CVE-2026-23249, CVE-2026-23266, CVE-2026-23267, CVE-2026-23272, CVE-2026-23278, CVE-2026-23392, CVE-2026-23428, CVE-2026-23450, CVE-2026-23455, CVE-2026-31402, CVE-2026-31411, CVE-2026-31418, CVE-2026-31436, CVE-2026-31448, CVE-2026-31478, CVE-2026-31607, CVE-2026-31637, CVE-2026-31649, CVE-2026-31657, CVE-2026-31659, CVE-2026-31668, CVE-2026-31669, CVE-2026-31676, CVE-2026-31682, CVE-2026-31685, CVE-2026-31687, CVE-2026-31693, CVE-2026-43011, CVE-2026-43037, CVE-2026-43038, CVE-2026-43071, CVE-2026-43114, CVE-2026-43117, CVE-2026-43123, CVE-2026-43124, CVE-2026-43128, CVE-2026-43130, CVE-2026-43132, CVE-2026-43133, CVE-2026-43134, CVE-2026-43135, CVE-2026-43136, CVE-2026-43137, CVE-2026-43139, CVE-2026-43140, CVE-2026-43141, CVE-2026-43143, CVE-2026-43145, CVE-2026-43147, CVE-2026-43148, CVE-2026-43149, CVE-2026-43150, CVE-2026-43152, CVE-2026-43153, CVE-2026-43156, CVE-2026-43157, CVE-2026-43158, CVE-2026-43159, CVE-2026-43163, CVE-2026-43167, CVE-2026-43168, CVE-2026-43169, CVE-2026-43170, CVE-2026-43171, CVE-2026-43173, CVE-2026-43175, CVE-2026-43180, CVE-2026-43182, CVE-2026-43183, CVE-2026-43184, CVE-2026-43186, CVE-2026-43187, CVE-2026-43189, CVE-2026-43190, CVE-2026-43194, CVE-2026-43196, CVE-2026-43199, CVE-2026-43200, CVE-2026-43201, CVE-2026-43202, CVE-2026-43203, CVE-2026-43205, CVE-2026-43206, CVE-2026-43207, CVE-2026-43209, CVE-2026-43211, CVE-2026-43212, CVE-2026-43214, CVE-2026-43215, CVE-2026-43218, CVE-2026-43221, CVE-2026-43222, CVE-2026-43223, CVE-2026-43225, CVE-2026-43226, CVE-2026-43227, CVE-2026-43230, CVE-2026-43231, CVE-2026-43232, CVE-2026-43233, CVE-2026-43236, CVE-2026-43238, CVE-2026-43239, CVE-2026-43241, CVE-2026-43242, CVE-2026-43244, CVE-2026-43246, CVE-2026-43248, CVE-2026-43249, CVE-2026-43250, CVE-2026-43251, CVE-2026-43253, CVE-2026-43255, CVE-2026-43256, CVE-2026-43257, CVE-2026-43258, CVE-2026-43261, CVE-2026-43262, CVE-2026-43264, CVE-2026-43266, CVE-2026-43268, CVE-2026-43269, CVE-2026-43270, CVE-2026-43271, CVE-2026-43273, CVE-2026-43275, CVE-2026-43277, CVE-2026-43278, CVE-2026-43279, CVE-2026-43283, CVE-2026-43287, CVE-2026-43288, CVE-2026-43289, CVE-2026-43291, CVE-2026-43295, CVE-2026-43296, CVE-2026-43297, CVE-2026-43300, CVE-2026-43302, CVE-2026-43304, CVE-2026-43312, CVE-2026-43313, CVE-2026-43314, CVE-2026-43315, CVE-2026-43316, CVE-2026-43317, CVE-2026-43318, CVE-2026-43319, CVE-2026-43320, CVE-2026-43341, CVE-2026-43378, CVE-2026-43383, CVE-2026-43384, CVE-2026-43406, CVE-2026-43407, CVE-2026-43414, CVE-2026-43493, CVE-2026-43494, CVE-2026-43501, CVE-2026-45847, CVE-2026-45848, CVE-2026-45849, CVE-2026-45851, CVE-2026-45852, CVE-2026-45856, CVE-2026-45857, CVE-2026-45859, CVE-2026-45860, CVE-2026-45861, CVE-2026-45862, CVE-2026-45864, CVE-2026-45865, CVE-2026-45866, CVE-2026-45867, CVE-2026-45868, CVE-2026-45869, CVE-2026-45870, CVE-2026-45871, CVE-2026-45872, CVE-2026-45873, CVE-2026-45875, CVE-2026-45877, CVE-2026-45878, CVE-2026-45879, CVE-2026-45880, CVE-2026-45881, CVE-2026-45882, CVE-2026-45883, CVE-2026-45884, CVE-2026-45885, CVE-2026-45886, CVE-2026-45890, CVE-2026-45891, CVE-2026-45893, CVE-2026-45895, CVE-2026-45902, CVE-2026-45904, CVE-2026-45905, CVE-2026-45910, CVE-2026-45912, CVE-2026-45913, CVE-2026-45914, CVE-2026-45915, CVE-2026-45916, CVE-2026-45917, CVE-2026-45919, CVE-2026-45921, CVE-2026-45923, CVE-2026-45928, CVE-2026-45935, CVE-2026-45936, CVE-2026-45938, CVE-2026-45941, CVE-2026-45946, CVE-2026-45947, CVE-2026-45948, CVE-2026-45954, CVE-2026-45957, CVE-2026-45960, CVE-2026-45962, CVE-2026-45964, CVE-2026-45965, CVE-2026-45968, CVE-2026-45969, CVE-2026-45970, CVE-2026-45972, CVE-2026-45973, CVE-2026-45974, CVE-2026-45976, CVE-2026-45978, CVE-2026-45981, CVE-2026-45982, CVE-2026-45983, CVE-2026-45984, CVE-2026-45988, CVE-2026-46043, CVE-2026-46115, CVE-2026-46119, CVE-2026-46135, CVE-2026-46185, CVE-2026-46195, CVE-2026-46243, CVE-2026-46244, CVE-2026-46246, CVE-2026-46247, CVE-2026-46249, CVE-2026-46250, CVE-2026-46251, CVE-2026-46253, CVE-2026-46254, CVE-2026-46255, CVE-2026-46259, CVE-2026-46260, CVE-2026-46261, CVE-2026-46265, CVE-2026-46266, CVE-2026-46267, CVE-2026-46270, CVE-2026-46289, CVE-2026-46323, CVE-2026-46328)

Tenable 已直接從 Ubuntu 安全公告擷取前置描述區塊。

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

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

  - 已解決 Linux 核心中的下列弱點：net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc :
    napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27:
    ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20:
    0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16:
    ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12:
    0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 :
    0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 :
    0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
    (CVE-2021-47400)

  - 已解決 Linux 核心中的下列弱點：can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() Using wait_event_interruptible() to wait for complete transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will result in TX buffer has multiple accessors and the later process interferes with the previous process.
    Following is one of the problems reported by syzbot.
    ============================================================= WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390
    __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80
    __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in isotp_sendmsg() to avoid multiple accessers for tx buffer. (CVE-2021-47457)

  - 已解決 Linux 核心中的下列弱點：serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 (tty: serial_core: convert uart_close to use tty_port_close) converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e (uart: fix race between uart_put_char() and uart_shutdown()). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace (tty/serial: do not free trasnmit buffer page under port lock)). (CVE-2021-47527)

  - 已解決 Linux 核心中的下列弱點：mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured.
    However, dax doesn't depend on hugetlb. Commit 414fd080d125 (mm/gup: fix gup_pmd_range() for dax) fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30
    __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100
    __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK>
    ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled (CVE-2022-48986)

  - 已解決 Linux 核心中的下列弱點：lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ (CVE-2022-49078)

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

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1780562693 公告中提及的多個弱點影響。

  - 在 5.16.12 之前的 Linux 核心中發現一個問題。drivers/net/usb/sr9700.c 允許攻擊者透過裝置的特製框架長度，從堆積記憶體取得敏感資訊。(CVE-2022-26966)

  - 已解決 Linux 核心中的下列弱點：kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k
    __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r
    __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table.
    Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
    aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list :
    show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop :
    warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at
    __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130
    __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm:
    execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP:
    0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10:
    0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- (CVE-2022-50008)

  - 已解決 Linux 核心中的下列弱點：tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write. [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28;
    int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51;
    int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63 >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \ events/sched/sched_waking/trigger # echo hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid) >> events/sched/sched_switch/trigger [2] BUG: unable to handle page fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU:
    2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09:
    0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3:
    0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX:
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

  - 已解決 Linux 核心中的下列弱點：net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done (CVE-2023-52887)

  - 已解決 Linux 核心中的下列弱點：net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. (CVE-2024-38553)

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

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

  - 在 Linux 核心中發現一個錯誤，此錯誤允許使用者空間呼叫位移和緩衝區長度爲零 memcpy_fromiovecend() 和類似函式，這會造成讀取超出緩衝區邊界，在某些情況下，藉由存取無效的記憶體位址，可造成記憶體存取錯誤和系統暫停。此問題僅影響 Red Hat Enterprise Linux 7 隨附的 3.10.x 版核心。(CVE-2018-16885)

  - 在 6.3.2 版之前的 Linux 核心中發現一個問題。在 drivers/media/pci/saa7134/saa7134-core.c 的 saa7134_finidev 中發現一個釋放後使用錯誤。(CVE-2023-35823)

  - 已解決 Linux 核心中的下列弱點：RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work.
    (CVE-2025-38024)

  - 已解決 Linux 核心中的下列弱點：RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80 (CVE-2026-23243)

  - 已解決 Linux 核心中的下列弱點：nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. (CVE-2026-31402)

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

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

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

    安全性修正：

    * 核心：nfsd：使用 rcu_work 發布 svc_expkey/svc_export (CVE-2024-53216)

    * kernel: scsi: qla2xxx：修正 purex 項目的不當釋放 (CVE-2025-68741)

    * 核心： Linux 核心：RDMA umad 中的拒絕服務和記憶體損毀 （CVE-2026-23243）

    * 核心：Linux 核心 KVM：由於影子頁面表格項目處理不當，導致權限提升或拒絕服務 （CVE-2026-23401）

    * kernel：crypto：algif_aead - 還原為異地操作模式 (CVE-2026-31431)

    * 核心：can：raw：修正 raw_rcv（） 中的 ro->uniq 釋放後使用 （CVE-2026-31532）

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

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

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

遠端 Oracle Linux 10 主機中安裝的套件受到 ELSA-2026-18134 公告中提及的多個弱點影響。

    - crypto： ccp - 使用 skcipher ivsize 複製 IV （CKI Backport Bot） [RHEL-188463] {CVE-2026-53016}
    - futex/requeue： 還原「防止 remove_waiter（） 中的 NULL 指標解除參照 on self-deadlock」 （CKI Backport Bot） [RHEL-193250] {CVE-2026-53166}
    - futex/requeue： 在自我鎖死時，防止 remove_waiter（） 中的 NULL 指標解除參照 （CKI Backport Bot） [RHEL-193250] {CVE-2026-43499}
    - locking/rtmutex：當服務員未排入佇列時，跳過 remove_waiter（） （CKI Backport Bot） [RHEL-193153] {CVE-2026-43499}
    - rtmutex：在 remove_waiter（） 中使用 waiter：：task 而不是當前 （CKI Backport Bot） [RHEL-193153] {CVE-2026-43499}
    - md/bitmap：修正write_page中由調整大小爭用引起的 GPF （Nigel Croxon） [RHEL-174092] {CVE-2026-43163}
    - KVM： x86：修正由於意外角色而導致的釋放後使用影子分頁 （Paolo Bonzini） [RHEL-192407] {CVE-2026-53359}
    - KVM： x86：修正由於意外的 GFN 而導致的釋放後使用影子分頁 （CKI Backport Bot） [RHEL-186698] {CVE-2026-46113}
    - net/sched： ets：在 ets_qdisc_change 中刪除類別之前，始終從活動清單中刪除類別 （CKI Backport Bot） [RHEL-183007] {CVE-2025-71066}
    - sctp：重新驗證 SCTP_SENDALL 中 sctp_sendmsg_to_asoc() 之後的清單游標 (CKI Backport Bot) [RHEL-179854] {CVE-2026-46227}
    - eventpoll：修正半無限遞迴 （Ian Kent） [RHEL-180776] {CVE-2025-38614}
    - eventpoll：修正ep_remove結構 eventpoll / 結構檔案 UAF （Ian Kent） [RHEL-180776] {CVE-2026-46242}
    - eventpoll：將結構 eventpoll 釋放時間推遲到 RCU 寬限期 （Ian Kent） [RHEL-173832] {CVE-2026-43074}
    - smb/client：修正 smb2_compound_op（） 中的越界讀取 （Paulo Alcantara） [RHEL-180048] {CVE-2026-46155}
    - procfs：修正在讀取 do_task_stat() 中的 real_parent 時缺少的 RCU 保護 (CKI Backport Bot) [RHEL-181902] {CVE-2026-46259}
    - net/ipv6： ioam6：防止追蹤填充中的結構描述長度環繞 （Antoine Tenart） [RHEL-174786] {CVE-2026-43341}
    - net/mana：設定錯誤時的 Null service_wq以防止雙重破壞 （CKI Backport Bot） [RHEL-180277] {CVE-2026-43276}
    - net： mana：修正服務重新掃描 PCI 路徑上的雙重destroy_workqueue （CKI Backport Bot） [RHEL-180277] {CVE-2026-43276}
    - fs/smb/client：修正 cifs_sanitize_prepath 中的超出邊界讀取弱點 (CKI Backport Bot) [RHEL-189491] {CVE-2026-43112}
    - 啟用 ARM64 ERRATUM 4118414 的解決辦法 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：勘誤表：緩解 Microsoft Azure Cobalt 100 CPU 中的 TLBI 勘誤表 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：勘誤表：緩解 NVIDIA Olympus CPU 中的 TLBI 勘誤表 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：勘誤表：緩解不同 Arm CPU 中的 TLBI 勘誤表 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：cputype：新增 C1-Ultra 定義 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：cputype：新增 C1-Premium 定義 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - arm64：cputype：新增 C1-Pro 定義 (Mark Salter) [RHEL-183592] {CVE-2025-10263}
    - KVM： arm64： vgic-its： 僅刪除已清除項目的翻譯快取參照 （CKI Backport Bot） [RHEL-183965] {CVE-2026-46316}
    - netfilter： nft_inner：修正 IPv6 inner_thoff不同步 （CKI Backport Bot） [RHEL-181936] {CVE-2026-46244}
    - drm/gem：修正 drm_gem_fb_init_with_funcs() 中不一致的平面尺寸計算 (CKI Backport Bot) [RHEL-179912] {CVE-2026-46209}
    - rxrpc： 修正 rxrpc_input_call_event（） 以僅取消共用 DATA 封包 （CKI Backport Bot） [RHEL-179566] {CVE-2026-45998}
    - rxrpc： 修正 skb_unshare（） 失敗後的潛在 UAF （CKI Backport Bot） [RHEL-179566] {CVE-2026-45998}
    - RDMA/mlx5：修正 mlx5_ib_dev_res_srq_init（） 中的錯誤路徑貫穿 （CKI Backport Bot） [RHEL-180001] {CVE-2026-46176}
    - crypto： tegra - 新增遺漏的CRYPTO_ALG_ASYNC （Vladislav Dronov） [RHEL-182759] {CVE-2026-31739}
    - RDMA/vmw_pvrdma：修正 pvrdma_alloc_ucontext() 錯誤路徑上的雙重釋放 (CKI Backport Bot) [RHEL-179965] {CVE-2026-46189}
    - ALSA： aloop：在格式變更停止期間修正對等執行階段 UAF （CKI Backport Bot） [RHEL-179317] {CVE-2026-46090}
    - ALSA: usb-audio：在靜音時新增超出邊界寫入健全性檢查 (CKI Backport Bot) [RHEL-173937] {CVE-2026-43279}
    - tcp：修正 tcp_v6_syn_recv_sock（） 中潛在的爭用 （Paolo Abeni） [RHEL-174242] {CVE-2026-43198}
    - scsi： qla2xxx： 完全修正 fcport 雙重釋放 （Ewan D. Milne） [RHEL-179755] {CVE-2026-43414}
    - RDMA/mana：移除 mana_ib_create_qp_rss（） 中的使用者可觸發 WARN_ON（） （CKI Backport Bot） [RHEL-180155] {CVE-2026-46117}
    - RDMA/iwcm：透過移除 work_list 來修正工作佇列清單損毀 （CKI Backport Bot） [RHEL-179665] {CVE-2026-45898}
    - rxrpc：修正 RESPONSE 驗證器剖析器 OOB 讀取 （CKI 反向移植機器人） [RHEL-171456] {CVE-2026-31636}
    - nvmet-tcp：修正 ICReq 處理和佇列拆卸之間的爭用 （CKI Backport Bot） [RHEL-180106] {CVE-2026-46135}
    - RDMA/mana： 驗證rx_hash_key_len （CKI 反向移植機器人） [RHEL-180090] {CVE-2026-46145}
    - ipv6： icmp：清除 ip6_err_gen_icmpv6_unreach（） 中的 skb2->cb[] （Guillaume Nault） [RHEL-172675] {CVE-2026-43038}
    - net/sched：修正導致頁面快取損毀的 pedit 部分 COW （Ivan Vecera） [RHEL-177380] {CVE-2026-46331}
    - exit：防止搶佔 oopsing TASK_DEAD 任務 （CKI Backport Bot） [RHEL-180009] {CVE-2026-46173}
    - crypto： caam - 修正長 hmac 金鑰上的溢位 （CKI Backport Bot） [RHEL-179769] {CVE-2026-43330}

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
325012	Ubuntu 22.04 LTS/24.04 LTS：Linux 核心 (低延遲) 弱點 (USN-8497-1)	Nessus	Ubuntu Local Security Checks	2026/7/3	2026/7/6	high
360748	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc多個弱點（ALMALINUX9.2：CLSA-2026：1779987841）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
361263	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個漏洞（ALMALINUX9.6：CLSA-2026：1780562693）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high
361392	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個弱點（CENTOS7：CLSA-2026：1785561693）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
312840	RHEL 9：核心 (RHSA-2026:14339)	Nessus	Red Hat Local Security Checks	2026/5/7	2026/5/8	high
328759	Oracle Linux 10：核心 (ELSA-2026-18134)	Nessus	Oracle Linux Local Security Checks	2026/7/21	2026/7/21	high

偵測

搜尋 Plugin

high

high

high

high

high

high