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

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

    btrfs：在 cow_file_range() 失敗時執行適當的 folio 清理 (CVE-2024-57976)

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

    kernel：對於 dup_mmap() 失敗和 uprobe 註冊要更加小心 (CVE-2025-21709)

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

    block：修正 sysfs 儲存方法中的佇列凍結與限制鎖定順序 (CVE-2025-21807)

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

    block：圍繞 sysfs ->store() 標記 GFP_NOIO (CVE-2025-21817)

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

    iommu/vt-d：避免在 WARN_ON_ONCE 之後使用 NULL (CVE-2025-21833)

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

    net：改善追踪核心通訊端存留期 (CVE-2025-21884)

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

    bnxt_en：正確遮罩 TX BD 中的 bd_cnt 欄位 (CVE-2025-22108)

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

    ext4：前往 ext4_setattr() 中的正確標籤「out_mmap_sem」(CVE-2025-22120)

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

    net_sched：hfsc：修正類別處理中的 UAF 弱點 (CVE-2025-37797)

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

    vmxnet3：修正 vmxnet3_process_xdp 中格式錯誤的封包大小 (CVE-2025-37799)

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

    driver core：修正 dev_uevent() 中可能發生的 NULL 指標解除參照 (CVE-2025-37800)

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

    fs/ntfs3：保持寫入作業不可部分完成 (CVE-2025-37806)

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

    bpf：修正 percpu hashmap 的 kmemleak 警告 (CVE-2025-37807)

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

    crypto：null - 使用微調鎖定而非 mutex (CVE-2025-37808)

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

    usb：typec：class：修正 NULL 指標存取 (CVE-2025-37809)

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

    usb：xhci：修正 Etron 因應措施中的無效指標解除參照 (CVE-2025-37813)

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

    tty：所有 TIOCL_SELMOUSEREPORT 的使用情況都需要 CAP_SYS_ADMIN (CVE-2025-37814)

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

    irqchip/gic-v2m：避免 gicv2m_get_fwnode() 釋放後使用 (CVE-2025-37819)

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

    xen-netfront：處理 xdp_convert_buff_to_frame() 傳回的 NULL (CVE-2025-37820)

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

    sched/eevdf：修正 se->slice 被設定為 U64_MAX 所導致的當機問題 (CVE-2025-37821)

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

    net_sched：hfsc：同時修正 hfsc_dequeue() 中的潛在 UAF (CVE-2025-37823)

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

    btrfs：zoned：傳回 RAID1 區塊群組寫入指標不符時的 EIO (CVE-2025-37827)

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

    mm/vmscan不嘗試回收 hwpoison 作品集 (CVE-2025-37834)

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

    netfs：僅使用 CONFIG_PROC_FS 建立 /proc/fs/netfs (CVE-2025-37876)

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

    iommu：清理時清除 iommu-dma 操作 (CVE-2025-37877)

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

    perf/core：修正部分 init 的 __free_event() 中的 WARN_ON(!ctx) (CVE-2025-37878)

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

    usb：xhci：修正等時環不足/溢位事件處理 (CVE-2025-37882)

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

    bpf：修正 rcu_tasks_trace 和 event_mutex 之間的鎖死。(CVE-2025-37884)

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

    KVM：x86：如果*新*路由無法張貼，則將 IRTE 重設為主機控制 (CVE-2025-37885)

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

    net/mlx5：修正 mlx5_create_{inner_,}ttc_table() 中的 null-ptr-deref (CVE-2025-37888)

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

    net_sched：hfsc：修正類別中 netem 作為子 qdisc 的 UAF 弱點 (CVE-2025-37890)

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

    net當 sk_state 為 TCP_TIME_WAIT 時使用 sock_gen_put() (CVE-2025-37894)

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

    iommu：修正 iommu_copy_struct_from_user() 中的兩個問題 (CVE-2025-37900)

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

    mm、slab一律清理 slab->obj_exts (CVE-2025-37908)

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

    net_sched：qfq：修正在 netem 作為子 qdisc 的類別中新增雙重清單 (CVE-2025-37913)

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

    net_sched：ets：修正在 netem 作為子 qdisc 的類別中新增雙重清單 (CVE-2025-37914)

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

    net_sched：drr：修正在 netem 作為子 qdisc 的類別中新增雙重清單 (CVE-2025-37915)

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

    xsk：修正 AF_XDP 通用 RX 路徑中的爭用情形 (CVE-2025-37920)

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

    vxlanvnifilter修正預設 FDB 項目的未鎖定刪除 (CVE-2025-37921)

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

    tracing：修正 trace_seq_to_buffer() 中的 oob 寫入 (CVE-2025-37923)

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

    iommu/amd：修正 parse_ivrs_acpihid 中的潛在緩衝區溢位 (CVE-2025-37927)

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

    dm-bufio：不在不可部分完成的內容中排程 (CVE-2025-37928)

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

    arm64：errata：將缺少的 sentinels 新增至 Spectre-BHB MIDR 陣列 (CVE-2025-37929)

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

    btrfs：根據磁區大小調整子頁面位元開始 (CVE-2025-37931)

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

    sch_htb：使 htb_qlen_notify() 具有冪等性 (CVE-2025-37932)

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

    perf/x86/intelKVM為具有 vCPU 值的來賓載入遮罩 PEBS_ENABLE。 (CVE-2025-37936)

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

    追踪驗證具有 %*p.. 的事件格式 (CVE-2025-37938)

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

    arm64：bpf：在 cBPF 程式的結尾新增 BHB 緩解措施 (CVE-2025-37948)

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

    xenbus：使用 kref 追踪 req 存留期 (CVE-2025-37949)

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

    smb用戶端避免 open_cached_dir 中發生租用中斷的爭用 (CVE-2025-37954)

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

    virtio-net在 virtnet_xsk_pool_enable() 中發生錯誤時釋放 xsk_buffs (CVE-2025-37955)

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

    KVM：SVM：在 SHUTDOWN 攔截時強制離開 SMM 模式 (CVE-2025-37957)

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

    mm/huge_memory：修正解除參照無效的 pmd 移轉項目 (CVE-2025-37958)

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

    bpf：在 bpf_redirect_peer 上對封包進行清理 (CVE-2025-37959)

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

    memblock：在 memblock_double_array() 中使用前接受配置的記憶體 (CVE-2025-37960)

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

    ipvs：修正 do_output_route4 中 saddr 的 uninit-value (CVE-2025-37961)

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

    arm64：bpf：僅緩解無權限使用者載入的 cBPF 程式 (CVE-2025-37963)

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

    x86/mm：消除可能會意外略過 TLB 更新的視窗 (CVE-2025-37964)

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

    usbtypec: class合作夥伴取消註冊時使 USB 裝置指標失效 (CVE-2025-37986)

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

    修正 do_move_mount() 處理 MNT_TREE_BENEATH 時發生的數個爭用問題 (CVE-2025-37988)

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

    net：phy：leds：修正記憶體洩漏 (CVE-2025-37989)

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

    module：確保 kobject_put() 對於模組類型 kobjects 而言是安全的 (CVE-2025-37995)

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

    netfilter：ipset：修正雜湊類型中的區域鎖定 (CVE-2025-37997)

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

    openvswitch：修正 output_userspace() 中不安全的屬性剖析 (CVE-2025-37998)

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

    fs/erofs/fileio在 bio_add_folio() 之後呼叫 erofs_onlinefolio_split() (CVE-2025-37999)

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

    sch_hfsc使 hfsc_qlen_notify() 等冪 (CVE-2025-38177)

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

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

遠端 Ubuntu 25.04 主機上安裝的套件受到 USN-7594-1 公告中所提及的多個弱點影響。

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

    - ARM32 架構;

    - ARM64 架構 ;

    - PowerPC 架構；

    - RISC-V 架構；

    - 使用者模式 Linux (UML)；

    - x86 架構；

    - 區塊層子系統；

    - 密碼編譯 API；

    - 計算加速架構；

    - ACPI 驅動程式；

    - Serial ATA 和 Parallel ATA 驅動程式；

    - 驅動程式核心；

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

    - 藍牙驅動程式;

    - 匯流排裝置；

    - TPM 裝置驅動程式；

    - 時鐘架構和驅動程式；

    - CPU 頻率縮放架構;

    - 緩衝區共用和同步處理架構;

    - DMA 引擎子系統;

    - GPU 驅動程式；

    - HID 子系統；

    - HSI 子系統;

    - I2C 子系統；

    - I3C 子系統;

    - IIO 子系統;

    - InfiniBand 驅動程式；

    - IOMMU 子系統；

    - IRQ 晶片驅動程式；

    - MCB 驅動程式;

    - 多個裝置驅動程式；

    - 媒體驅動程式；

    - MemoryStick 子系統；

    - 多功能裝置驅動程式；

    - Microchip PCI 驅動程式;

    - Intel Management Engine 介面驅動程式

    - PCI Endpoint Test 驅動程式;

    - MTD 區塊裝置驅動程式；

    - 網路驅動程式；

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

    - Mellanox 網路驅動程式；

    - STMicroelectronics 網路驅動程式；

    - NTB 驅動程式；

    - NVME 驅動程式；

    - PCI 子系統；

    - Synopsys DesignWare PCIe PMU

    - Mellanox 平台驅動程式

    - PWM 驅動程式;

    - Remote Processor 子系統;

    - S/390 驅動程式 ;

    - SCSI 子系統；

    - Samsung SoC 驅動程式;

    - SPI 子系統；

    - GPIB 驅動程式

    - VideoCore 服務驅動程式；

    - 熱驅動程式；

    - TTY 驅動程式；

    - UFS 子系統;

    - Cadence USB3 驅動程式;

    - ChipIdea USB 驅動程式;

    - USB 裝置類別驅動程式；

    - DesignWare USB3 驅動程式 ;

    - USB Gadget 驅動程式；

    - USB 主機控制器驅動程式；

    - USB Type-C 支援驅動程式；

    - Virtio Host (VHOST) 子系統;

    - 背光驅動程式；

    - Framebuffer 層；

    - W1 Dallas 的單線匯流排驅動程式；

    - 9P 分散式檔案系統 ;

    - 檔案系統基礎架構 ;

    - BTRFS 檔案系統 ;

    - Ext4 檔案系統;

    - F2FS 檔案系統;

    - JFS 檔案系統;

    - 網路檔案系統程式庫;

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

    - NTFS3 檔案系統；

    - 重疊檔案系統；

    - SMB 網路檔案系統；

    - 乙太網路橋接器；

    - io_uring 子系統;

    - Perf 事件；

    - 記憶體管理；

    - UProbes 追蹤；

    - Amateur Radio 驅動程式；

    - SCTP 通訊協定；

    - 網路通訊端；

    - RDMA 動詞 API；

    - BPF 子系統；

    - 核心 fork() 系統呼叫；

    - 休眠控制

    - 排程器基礎架構；

    - 追蹤基礎架構；

    - 觀察佇列通知機制；

    - Vector I/O iterator 程式庫

    - 802.1Q VLAN 通訊協定；

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

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

    - 網路核心；

    - 分散式交換架構;

    - Ethtool 驅動程式；

    - IPv4 網路 ;

    - IPv6 網路；

    - MAC80211 子系統；

    - 管理元件傳輸通訊協定 (MCTP)；

    - 多重路徑 TCP;

    - Netfilter；

    Open vSwitch；

    - 網路流量控制；

    - TIPC 通訊協定；

    - TLS 通訊協定；

    - 無線網路 ；

    - ALSA 架構;

    - WCD 音訊轉碼器

    - 適用於 Freescale CPU 的 SoC Audio 驅動程式 ;

    - SoC Audio 通用驅動程式

    - Intel ASoC 驅動程式;

    - QCOM ASoC 驅動程式；

    - Virtio sound 驅動程式;

    - CPU電源監控子系統；(CVE-2025-37806, CVE-2025-22084, CVE-2025-39688, CVE-2025-22030, CVE-2025-37754, CVE-2025-37783, CVE-2025-37825, CVE-2025-37752, CVE-2025-22104, CVE-2025-40014, CVE-2025-22103, CVE-2025-37874, CVE-2025-37773, CVE-2025-37741, CVE-2025-37763, CVE-2025-37859, CVE-2025-37779, CVE-2025-23155, CVE-2025-23143, CVE-2025-37788, CVE-2025-22028, CVE-2024-58096, CVE-2025-37842, CVE-2025-37854, CVE-2025-38637, CVE-2024-58097, CVE-2023-53034, CVE-2025-37797, CVE-2025-37851, CVE-2025-37941, CVE-2025-37942, CVE-2025-37748, CVE-2025-37982, CVE-2025-22058, CVE-2025-37781, CVE-2025-23130, CVE-2025-23149, CVE-2025-23146, CVE-2025-37809, CVE-2025-37801, CVE-2025-22080, CVE-2025-23160, CVE-2025-37823, CVE-2025-37827, CVE-2025-39755, CVE-2025-22124, CVE-2025-22033, CVE-2025-22075, CVE-2025-37850, CVE-2025-37757, CVE-2025-22060, CVE-2025-37979, CVE-2025-22098, CVE-2025-39989, CVE-2025-37989, CVE-2025-37790, CVE-2025-37885, CVE-2025-37875, CVE-2025-22066, CVE-2025-37975, CVE-2025-37819, CVE-2025-37755, CVE-2025-37794, CVE-2025-23148, CVE-2025-22067, CVE-2025-22061, CVE-2025-22109, CVE-2025-37884, CVE-2025-37852, CVE-2025-37866, CVE-2025-37872, CVE-2025-37751, CVE-2025-23156, CVE-2025-22065, CVE-2025-37837, CVE-2025-22069, CVE-2025-37822, CVE-2025-22128, CVE-2025-22087, CVE-2025-22023, CVE-2025-22038, CVE-2025-22096, CVE-2025-22076, CVE-2025-22045, CVE-2025-38049, CVE-2025-37870, CVE-2025-37939, CVE-2025-37865, CVE-2025-37860, CVE-2025-37771, CVE-2025-23144, CVE-2025-22081, CVE-2025-39778, CVE-2025-23153, CVE-2025-22036, CVE-2025-23154, CVE-2025-22101, CVE-2025-37808, CVE-2025-37772, CVE-2025-22070, CVE-2025-37789, CVE-2025-22025, CVE-2025-22019, CVE-2025-37868, CVE-2025-22083, CVE-2025-22095, CVE-2025-23161, CVE-2025-22027, CVE-2025-37843, CVE-2025-37985, CVE-2025-23132, CVE-2025-22073, CVE-2025-37940, CVE-2025-23140, CVE-2025-37828, CVE-2025-22063, CVE-2025-22053, CVE-2025-37787, CVE-2025-23152, CVE-2025-37840, CVE-2025-22118, CVE-2025-37981, CVE-2025-22111, CVE-2025-22091, CVE-2025-37841, CVE-2025-23142, CVE-2025-37838, CVE-2025-37775, CVE-2025-23147, CVE-2025-22022, CVE-2025-37745, CVE-2025-37785, CVE-2025-37821, CVE-2025-37988, CVE-2025-37986, CVE-2025-23138, CVE-2025-37836, CVE-2025-37792, CVE-2025-23141, CVE-2025-23159, CVE-2025-38240, CVE-2025-37764, CVE-2025-22120, CVE-2025-37881, CVE-2025-37777, CVE-2025-37987, CVE-2025-37811, CVE-2025-22032, CVE-2025-22044, CVE-2025-37943, CVE-2025-37802, CVE-2025-37829, CVE-2025-37862, CVE-2025-38575, CVE-2025-37799, CVE-2025-37882, CVE-2025-37812, CVE-2025-37765, CVE-2025-37813, CVE-2025-37980, CVE-2025-37873, CVE-2025-37766, CVE-2025-37761, CVE-2025-37892, CVE-2025-22094, CVE-2025-22035, CVE-2025-22055, CVE-2025-22100, CVE-2025-37816, CVE-2025-22062, CVE-2025-22110, CVE-2025-22088, CVE-2025-23129, CVE-2025-38479, CVE-2025-37740, CVE-2025-23136, CVE-2025-37846, CVE-2025-23163, CVE-2025-37977, CVE-2025-37879, CVE-2025-22082, CVE-2025-22046, CVE-2025-22050, CVE-2025-22126, CVE-2025-37796, CVE-2025-37815, CVE-2025-22127, CVE-2025-22105, CVE-2025-22068, CVE-2025-22119, CVE-2025-22089, CVE-2025-37858, CVE-2025-37826, CVE-2025-37945, CVE-2025-23157, CVE-2025-22054, CVE-2025-37805, CVE-2025-37856, CVE-2025-37878, CVE-2025-37768, CVE-2025-22040, CVE-2025-37944, CVE-2025-37774, CVE-2025-22117, CVE-2025-37888, CVE-2025-37857, CVE-2025-37791, CVE-2025-37817, CVE-2025-22041, CVE-2025-37983, CVE-2025-22039, CVE-2025-37749, CVE-2025-22097, CVE-2025-37747, CVE-2025-37762, CVE-2025-22114, CVE-2025-37831, CVE-2025-23133, CVE-2025-22020, CVE-2025-22085, CVE-2025-37807, CVE-2025-22059, CVE-2025-22042, CVE-2025-22123, CVE-2025-22107, CVE-2025-37759, CVE-2024-58094, CVE-2025-40114, CVE-2025-37810, CVE-2025-37833, CVE-2025-23134, CVE-2025-23151, CVE-2025-37743, CVE-2025-22034, CVE-2025-37739, CVE-2025-37863, CVE-2025-39735, CVE-2025-39930, CVE-2025-37847, CVE-2025-37803, CVE-2025-37786, CVE-2025-22112, CVE-2025-37830, CVE-2025-22108, CVE-2025-37767, CVE-2025-37814, CVE-2025-37798, CVE-2025-22086, CVE-2025-37778, CVE-2024-58093, CVE-2025-37848, CVE-2025-22024, CVE-2025-37776, CVE-2025-38104, CVE-2025-37938, CVE-2025-37861, CVE-2025-23150, CVE-2025-22021, CVE-2025-22018, CVE-2025-23137, CVE-2025-37756, CVE-2025-37784, CVE-2025-37769, CVE-2025-37820, CVE-2025-37758, CVE-2025-22047, CVE-2025-37844, CVE-2025-22093, CVE-2025-23162, CVE-2025-22051, CVE-2025-22115, CVE-2025-37845, CVE-2025-22074, CVE-2025-37883, CVE-2025-22116, CVE-2025-37824, CVE-2025-22052, CVE-2025-22090, CVE-2025-37750, CVE-2025-39728, CVE-2025-23145, CVE-2025-22125, CVE-2025-37834, CVE-2025-37738, CVE-2025-37760, CVE-2025-22079, CVE-2025-37877, CVE-2025-37849, CVE-2025-22026, CVE-2025-37886, CVE-2025-22043, CVE-2025-22122, CVE-2025-37937, CVE-2025-22071, CVE-2025-37742, CVE-2025-37744, CVE-2025-22106, CVE-2025-38152, CVE-2025-37869, CVE-2025-23135, CVE-2025-22056, CVE-2024-58095, CVE-2025-37853, CVE-2025-37770, CVE-2025-22031, CVE-2025-23158, CVE-2025-22072, CVE-2025-22102, CVE-2025-40325, CVE-2025-22037, CVE-2025-37876, CVE-2025-37864, CVE-2025-37867, CVE-2025-37855, CVE-2025-37984, CVE-2025-37839, CVE-2025-23131, CVE-2025-22121, CVE-2025-22078, CVE-2025-37800, CVE-2025-37880, CVE-2025-37925, CVE-2025-22113, CVE-2025-22064, CVE-2025-22057, CVE-2025-22092, CVE-2025-37780, CVE-2025-37887, CVE-2025-22099, CVE-2025-37793, CVE-2025-37978, CVE-2025-37746)

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

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

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

  - 已解決 Linux 核心中的下列弱點：phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. (CVE-2021-47416)

  - 在 Linux 核心的 TeleTYpe 子系統中發現超出邊界讀取缺陷。由於 flush_to_ldisc 函式中存在記憶體洩漏弱點，使用者利用 ioctls 的 TIOCSPTLCK、TIOCGPTPEER、TIOCSTI 和 TCXONC 觸發爭用情形時會發生此問題。本機使用者可利用此缺陷造成系統當機，或從記憶體讀取未經授權的隨機資料。(CVE-2022-1462)

  - 已解決 Linux 核心中的下列弱點：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已解決 Linux 核心中的下列弱點：tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ----
    ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key);
    lock(&port->lock); lock(console_owner); As commit dbdda842fe96 (printk: Add console owner and waiter logic to load balance console writes) said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
    ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock:
    ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
    tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key);
    call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
    vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- (CVE-2022-49441)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

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

遠端 Oracle Linux 10 / 9 主機已安裝受到多個弱點影響的套件如 ELSA-2025-20530 公告中所提及。

    - sunrpc將 svc 驗證處理期間視為驗證錯誤的 SVC_GARBAGE處理 (Jeff Layton) [Orabug: 38137447] {CVE-2025-38089}
    - 新增 Zen34 用戶端 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/處理程序將緩衝區清除移至 MONITOR 之前 (Kim Phillips) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - 新增一般計數器 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM將 TSA CPUID 位元公告給客體 (Borislav Petkov (AMD)) [Orabug38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤新增暫時性排程器攻擊緩解 (Borislav Petkov (AMD)) [Orabug38172252] {CVE-2024-36350} {CVE-2024-36357}

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

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

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

  - mm/vmscan不嘗試回收 hwpoison 作品集 Syzkaller 報告如下錯誤在處理程序虛擬位址 0x20ffd000 插入 pfn 0x18b00e 的記憶體失敗 記憶體失敗0x18b00e已變更的 swapcache 頁面仍由 2 個使用者參照記憶體失敗0x18b00e復原針對已變更 swapcache 頁面的動作
    失敗頁面refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon 旗標
    0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw
    005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 原始 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 頁面已轉儲存()
    ------------[ 截到此處 ]------------ mm/swap_state.c:184! 的核心錯誤內部錯誤Oops - 錯誤
    00000000f2000800 [#1] SMP 模組連結於 CPU0 PID60 通訊 kswapd0 未受污染的 6.6.0-gcb097e7de84e #3 硬體名稱 linux,dummy-virt (DT) pstate80400005 (Nzcv daif +PAN -UAO - TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29 ffff800087f37340 x28
    fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19:
    fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10:
    ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 :
    ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214 /0x230 ret_from_fork+0x10/0x20透過下列步驟可重現此問題1) 回收處理程序隔離已變更的 swapcache 頁面且頁面未鎖定時頁面的插入記憶體失敗。
    me_swapcache_dirty() 會清除 uptodate 旗標並嘗試從 lru 刪除但失敗。回收處理程序會將 hwpoisoned 頁面放回 lru。 2) 對應 hwpoisoned 頁面的處理程序結束且頁面遭到刪除時該頁面將永遠不會被釋放並將永遠存在於 lru 中。 3) 如果我們再次觸發回收並嘗試回收頁面add_to_swap() 將會觸發 VM_BUG_ON_FOLIO因為 uptodate 旗標已清除。
    若要修正此問題請略過 shrink_folio_list() 中的 hwpoisoned 頁面。此外hwpoison_user_mappings() 可能尚未取消對應 hwpoison 作品集請在 shrink_folio_list() 中取消對應否則 hwpoison_user_mappings() 將無法取消對應該作品集因為該作品集不在 lru 清單中。 (CVE-2025-37834)

請注意，Nessus 依賴供應商報告的套件存在。

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

    - sunrpc在 svc 驗證處理期間將 SVC_GARBAGE視為驗證錯誤處理 (Jeff Layton) [Orabug: 38178286] {CVE-2025-38089}
    - 新增 Zen34 用戶端 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/處理程序將緩衝區清除移至 MONITOR 之前 (Kim Phillips) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - 新增一般計數器 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM將 TSA CPUID 位元公告給客體 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤新增暫時性排程器攻擊緩解 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/錯誤將 MDS 機器重新命名為更通用的名稱 (Borislav Petkov (AMD)) [Orabug38023239] {CVE-2024-36350} {CVE-2024-36357}
    - block修正將作品集新增到 bio 的問題 (Ming Lei) [Orabug: 37844657] {CVE-2025-22122}
    - f2fs修正以避免存取未初始化的 curseg (Chao Yu) [Orabug: 37844644] {CVE-2025-22123}
    - gpiovirtuser修正潛在的超出邊界寫入 (Markus Burri) [Orabug: 38095181] {CVE-2025-38082}
    - net_schedhfsc將類別新增至 eltree 的可重入入列解決兩次 (Pedro Tammela) [Orabug:
    38049363] {CVE-2025-38001}
    - smb用戶端修正 cifs_fill_dirent 中的釋放後使用 (Zhaolong Wang) [Orabug: 38094970] {CVE-2025-38051}
    - platform/x86dell-wmi-sysman避免 current_password_store() 中發生緩衝區溢位 (Vladimir Moskovkin) [Orabug: 38095141] {CVE-2025-38077}
    - ALSApcm修正 PCM OSS 層的緩衝區存取爭用 (Takashi Iwai) [Orabug: 38095145] {CVE-2025-38078}
    - canbcm針對 procfs 內容新增缺少的 rcu 讀取保護 (Oliver Hartkopp) [Orabug: 38049369] {CVE-2025-38003}
    - canbcm為 bcm_op 運行時間更新新增鎖定 (Oliver Hartkopp) [Orabug: 38049374] {CVE-2025-38004}
    - padata不洩漏 reorder_work 中的 refcount (Dominik Grzegorzek) [Orabug: 38094842] {CVE-2025-38031}
    - cryptoalgif_hash - 修正 hash_accept 中的重複釋放 (Ivan Pravdin) [Orabug: 38095153] {CVE-2025-38079}
    - net/tipc修正 tipc_aead_encrypt_done 中的 slab-use-after-free 讀取 (Wang Liang) [Orabug: 38094978] {CVE-2025-38052}
    - sch_hfsc修正在 hfsc_enqueue() 中使用 peek 時的 qlen 計量錯誤 (Cong Wang) [Orabug: 38049357] {CVE-2025-38000}
    - idpf修正 idpf_features_check 中的 null-ptr-deref (Pavan Kumar Linga) [Orabug: 38094982] {CVE-2025-38053}
    - ptpocp限制摘要輸出函式中的訊號/頻率計數 (Sagi Maimon) [Orabug: 38094984] {CVE-2025-38054}
    - perf/x86/intel使用 sample_freq 修正 PEBS-via-PT 的 segfault (Adrian Hunter) [Orabug: 38094988] {CVE-2025-38055}
    - ASoCSOFIntelhda重新載入模組時修正 UAF (Tavian Barnes) [Orabug: 38094991] {CVE-2025-38056}
    - espintcp修正 skb 洩漏 (Sabrina Dubroca) [Orabug: 38094993] {CVE-2025-38057}
    - __legitimize_mnt()MNT_SYNC_UMOUNT 的檢查應位於 mount_lock 之下 (Al Viro) [Orabug38095000] {CVE-2025-38058}
    - x86/Kconfig使 CFI_AUTO_DEFAULT 相依於 !RUST 或 Rust >= 1.88 (Pawel Anikiel) [Orabug38094847] {CVE-2025-38033}
    - btrfs如果沒有有效的 csum 樹狀結構避免 NULL 指標解除參照 (Qu Wenruo) [Orabug: 38095010] {CVE-2025-38059}
    - btrfs更正 btrfs__prelim_ref 中 prelim_ref 引數的順序 (Goldwyn Rodrigues) [Orabug:
    38094856] {CVE-2025-38034}
    - nvmet-tcp不還原 null sk_state_change (Alistair Francis) [Orabug: 38094863] {CVE-2025-38035}
    - vxlan註釋 FDB 資料爭用 (Ido Schimmel) [Orabug: 38094879] {CVE-2025-38037}
    - cpufreqamd-pstate移除 set_boost 中不必要的 driver_lock (Dhananjay Ugwekar) [Orabug: 38094888] {CVE-2025-38038}
    - drm/amd/display增加 block_sequence 陣列大小 (Joshua Aberback) [Orabug: 38095164] {CVE-2025-38080}
    - bpfcopy_verifier_state() 應複製 'loop_entry' 欄位 (Eduard Zingerman) [Orabug: 38095018] {CVE-2025-38060}
    - serialmctrl_gpio將 disable_ms 分割為 sync 和 no_sync API (Alexis Lothore) [Orabug: 38094901] {CVE-2025-38040}
    - net: pktgen修正 pktgen_thread_write() 中使用者指定緩衝區之外的存取 (Peter Seiderer) [Orabug:
    38095024] {CVE-2025-38061}
    - genirq/msi將 IOMMU IOVA 直接儲存在 msi_desc 中而非 iommu_cookie 中 (Jason Gunthorpe) [Orabug:
    38095031] {CVE-2025-38062}
    - dm修正由 REQ_PREFLUSH 造成的無條件 IO 節流 (Jinliang Zheng) [Orabug: 38095038] {CVE-2025-38063}
    - firmwarearm_ffa針對 ffa 裝置設定 dma_mask (Viresh Kumar) [Orabug: 38094925] {CVE-2025-38043}
    - mediacx231xx設定 417 的 device_caps (Hans Verkuil) [Orabug: 38094934] {CVE-2025-38044}
    - Orangefs不截斷檔案大小 (Matthew Wilcox) [Orabug: 38095056] {CVE-2025-38065}
    - dm cache透過封鎖失敗的裝置恢復時的重試來防止 BUG_ON (Ming-Hung Tsai) [Orabug
    38095063] {CVE-2025-38066}
    - cryptolzo - 修正壓縮緩衝區滿溢 (Herbert Xu) [Orabug: 38095079] {CVE-2025-38068}
    - PCI: endpoint: pci-epf-test修正導致核心 oops 的重複釋放 (Christian Bruel) [Orabug
    38095087] {CVE-2025-38069}
    - wifiiwlwifi修正除錯動作順序 (Johannes Berg) [Orabug: 38094942] {CVE-2025-38045}
    - x86/mm檢查 memblock_phys_alloc_range() 的傳回值 (Philip Redkin) [Orabug: 38095101] {CVE-2025-38071}
    - libnvdimm/labels修正 nd_label_data_init() 中的除法錯誤 (Robert Richter) [Orabug: 38095109] {CVE-2025-38072}
    - spi-rockchip修正暫存器超出邊界存取 (Luis de Arquer) [Orabug: 38095173] {CVE-2025-38081}
    - x86/fred修正在啟用 FRED 的情況下 S4 恢復期間發生的系統懸置 (Xin Li) [Orabug: 38094951] {CVE-2025-38047}
    - block修正 set_blocksize 和讀取路徑之間的爭用 (Darrick J. Wong) [Orabug: 38095117] {CVE-2025-38073}
    - virtio_ring將 KCSAN 的 event_triggered 標記為 racy進而修正資料爭用 (Zhongqiu Han) [Orabug
    38094958] {CVE-2025-38048}
    - scsi目標iscsi修正刪除的連線逾時 (Dmitry Bogdanov) [Orabug: 38095134] {CVE-2025-38075}
    - usbtypecucsidisplayport修正鎖死 (Andrei Kuzynski) [Orabug: 37977018] {CVE-2025-37967}
    - 藍牙btnxpuart修正 FW 釋放期間的核心錯誤 (Neeraj Sanjay Kale) [Orabug: 37844459] {CVE-2025-22102}
    - iiolightopt3001修正因並行旗標存取造成的鎖死 (Luca Ceresoli) [Orabug: 37977026] {CVE-2025-37968}
    - mm/page_alloc修正未接受的記憶體處理中的爭用情形 (Kirill A. Shutemov) [Orabug: 38094767] {CVE-2025-38008}
    - dmaengineidxd使用 idxd_cleanup() 協助程式重構移除呼叫 (Shuai Xue) [Orabug: 38094790] {CVE-2025-38014}
    - dmaengineidxd修正 idxd_alloc 錯誤處理路徑中的記憶體洩漏 (Shuai Xue) [Orabug: 38094793] {CVE-2025-38015}
    - dmaengineti: k3-udma新增缺少的鎖定 (Ronald Wahl) [Orabug: 38094756] {CVE-2025-38005}
    - wifimt76移除驅動程式時停用 napi (Fedor Pchelkin) [Orabug: 38094770] {CVE-2025-38009}
    - phytegraxusb使用位元遮罩進行 UTMI pad 電源狀態追踪 (Wayne Chang) [Orabug: 38094777] {CVE-2025-38010}
    - drm/amdgpucsa 取消對應使用不中斷的鎖定 (Philip Yang) [Orabug: 38094779] {CVE-2025-38011}
    - HIDbpf如果裝置遭到損毀則中止分派 (Rongrong) [Orabug: 38094796] {CVE-2025-38016}
    - sched_extbpf_iter_scx_dsq_new() 應一律初始化 iterator (Tejun Heo) [Orabug: 38094786] {CVE-2025-38012}
    - net/tls修正 alloc_page 失敗時發生的核心錯誤 (Pengtao He) [Orabug: 38094802] {CVE-2025-38018}
    - mlxswspectrum_router刪除 GRE 網路裝置時修正釋放後使用 (Ido Schimmel) [Orabug:
    38094804] {CVE-2025-38019}
    - wifi: mac80211配置 struct cfg80211_scan_request 後設定 n_channels (Kees Cook) [Orabug:
    38094788] {CVE-2025-38013}
    -ulatormax20086修正無效的記憶體存取 (Cosmin Tanislav) [Orabug: 38094833] {CVE-2025-38027}
    - net/mlx5e停用上傳連結代表設定檔的 MACsec 卸載 (Carolina Jubran) [Orabug: 38094808] {CVE-2025-38020}
    - net_sched在 ->change() 期間也排清 gso_skb 清單 (Cong Wang) [Orabug: 37998128] {CVE-2025-37992}
    - RDMA/核心修正「KASAN: slab-use-after-free Read in ib_register_device」問題 (Zhu Yanjun) [Orabug:
    38094813] {CVE-2025-38022}
    - nfs處理解除鎖定路徑中的 nfs_get_lock_context 失敗 (Li Lingfeng) [Orabug: 38094818] {CVE-2025-38023}
    - HIDuclogic在 uclogic_input_configured() 中新增 NULL 檢查 (Henry Martin) [Orabug: 38094764] {CVE-2025-38007}
    - RDMA/rxe修正 rxe_queue_cleanup 錯誤中的 slab-use-after-free Read (Zhu Yanjun) [Orabug38094827] {CVE-2025-38024}
    - arm64bpf僅緩解無權限使用者載入的 cBPF 程式 (James Morse) [Orabug: 37977004] {CVE-2025-37963}
    - arm64bpf將 BHB 緩解措施新增至 cBPF 程式的結尾 (James Morse) [Orabug: 37976926] {CVE-2025-37948}
    - usbtypecucsi: displayport修正 NULL 指標存取 (Andrei Kuzynski) [Orabug: 38015126] {CVE-2025-37994}
    - module確保 kobject_put() 對於模組類型 kobjects 是安全的 (Dmitry Antipov) [Orabug: 38015131] {CVE-2025-37995}
    - memblock在 memblock_double_array() 中使用前接受配置的記憶體 (Tom Lendacky) [Orabug:
    37976994] {CVE-2025-37960}
    - xenbus使用 kref 追踪 req 存留期 (Jason Andryuk) [Orabug: 37976934] {CVE-2025-37949}
    - smbclient避免租用中斷在 open_cached_dir 中發生爭用 (Paul Aurich) [Orabug: 37976959] {CVE-2025-37954}
    - drm/amd/display修正 dml 協助程式中的無效內容錯誤 (Roman Li) [Orabug: 37977185] {CVE-2025-37965}
    - drm/v3d如果略過重設則新增工作至擱置清單 (Maira Canal) [Orabug: 37976942] {CVE-2025-37951}
    - iio: imu: st_lsm6dsx修正 st_lsm6dsx_read_tugged_fifo 中可能的鎖定 (Silvano Seva) [Orabug:
    37977031] {CVE-2025-37969}
    - iioimu st_lsm6dsx修正 st_lsm6dsx_read_fifo 中可能的鎖定 (Silvano Seva) [Orabug: 37977037] {CVE-2025-37970}
    - KVMSVM在 SHUTDOWN 攔截時強制離開 SMM 模式 (Mikhail Lobanov) [Orabug: 37976977] {CVE-2025-37957}
    - mm/huge_memory修正無效的 pmd 移轉項目解除參照 (Gavin Guo) [Orabug: 37976982] {CVE-2025-37958}
    - x86/mm消除可能會意外略過 TLB 排清的視窗 (Dave Hansen) [Orabug: 37977013] {CVE-2025-37964}
    - stagingbcm2835-camera初始化 v4l2_dev 中的 dev (Dave Stevenson) [Orabug: 37977042] {CVE-2025-37971}
    - Input: mtk-pmic-keys - 修正可能的 null 指標解除參照 (Gary Bisson) [Orabug: 37977044] {CVE-2025-37972}
    - bpf在 bpf_redirect_peer 上抹除封包 (Paul Chaignon) [Orabug: 37976990] {CVE-2025-37959}
    - netfilteripset修正雜湊類型中的區域鎖定 (Jozsef Kadlecsik) [Orabug: 38015141] {CVE-2025-37997}
    - ipvs修正 do_output_route4 中 saddr 的 uninit-value (Julian Anastasov) [Orabug: 37976996] {CVE-2025-37961}
    - canm_canm_can_class_allocate_dev()初始化裝置探查上的微調鎖定 (Antonios Salios) [Orabug
    38015123] {CVE-2025-37993}
    - virtio-net在 virtnet_xsk_pool_enable() 中發生錯誤時釋放 xsk_buffs (Jakub Kicinski) [Orabug: 37976969] {CVE-2025-37955}
    - sch_htb使 htb_deactivate() 等冪 (Cong Wang) [Orabug: 37977176] {CVE-2025-37953}
    - ksmbd修正 parse_lease_state() 中的記憶體洩漏 (Zhaolong Wang) [Orabug: 37977180] {CVE-2025-37962}
    - openvswitch修正 output_userspace() 中不安全的屬性剖析 (Eelco Chaudron) [Orabug: 38015148] {CVE-2025-37998}
    - ksmbd修正 __close_file_table_ids 中的 UAF (Sean Heelan) [Orabug: 37976951] {CVE-2025-37952}
    - ksmbd透過驗證 *pos 來防止越界資料流寫入 (Norbert Szetei) [Orabug: 37976923] {CVE-2025-37947}
    - ksmbd防止使用空白字串重新命名 (Namjae Jeon) [Orabug: 37976972] {CVE-2025-37956}
    - s390/pci當 PF 具有子 VF 時在 disable_slot() 中修正重複的 pci_dev_put() (Niklas Schnelle) [Orabug:
    37976920] {CVE-2025-37946}
    - wificfg80211修正多重連結元素重組期間的超出邊界存取 (Veerendranath Jakkam) [Orabug: 37977046] {CVE-2025-37973}
    - s390/pci修正遺漏的 zpci_create_device() 錯誤傳回檢查 (Niklas Schnelle) [Orabug: 37977050] {CVE-2025-37974}
    - fs/erofs/fileio在 bio_add_folio() 之後呼叫 erofs_onlinefolio_split() (Max Kellermann) [Orabug:
    38015155] {CVE-2025-37999}
    - mlxbf-bootctl在 secure_boot_fuse_state_show() 中使用 sysfs_emit_at() (David Thompson) [Orabug:
    37964051,38037120] {CVE-2025-37866}

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

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

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

  - 已解決 Linux 核心中的下列弱點：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已解決 Linux 核心中的下列弱點：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已解決 Linux 核心中的下列弱點：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已解決 Linux 核心中的下列弱點：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

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

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

  - 已解決 Linux 核心中的下列弱點：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已解決 Linux 核心中的下列弱點：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已解決 Linux 核心中的下列弱點：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已解決 Linux 核心中的下列弱點：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
238280	Amazon Linux 2023：bpftool、kernel6.12、kernel6.12-modules-extra (ALAS2023-2025-994)	Nessus	Amazon Linux Local Security Checks	2025/6/12	2026/2/13	high
240657	Ubuntu 25.04：Linux 核心弱點 (USN-7594-1)	Nessus	Ubuntu Local Security Checks	2025/6/26	2026/1/6	high
352871	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783791447）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	medium
252244	Oracle Linux 10 / 9Unbreakable Enterprise 核心 (ELSA-2025-20530)	Nessus	Oracle Linux Local Security Checks	2025/8/19	2026/2/9	medium
250070	Linux Distros 未修補的弱點：CVE-2025-37834	Nessus	Misc.	2025/8/15	2026/9/2	medium
242347	Oracle Linux 9：Unbreakable Enterprise 核心 (ELSA-2025-20480)	Nessus	Oracle Linux Local Security Checks	2025/7/18	2026/2/9	medium
360724	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	high
360889	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high

偵測

搜尋 Plugin

high

high

medium

medium

medium

medium

high

high