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

  - 已解決 Linux 核心中的下列弱點：idpf: check error for register_netdev() on init Current init logic ignores the error code from register_netdev(), which will cause WARN_ON() on attempt to unregister it, if there was one, and there is no info for the user that the creation of the netdev failed. WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641] unregister_netdev+0x1c/0x30 [3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf] [3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739] idpf_remove+0xbf/0x780 [idpf] [3707.563769] pci_device_remove+0xab/0x1e0 [ 3707.563786] device_release_driver_internal+0x371/0x530 [3707.563803] driver_detach+0xbf/0x180 [ 3707.563816] bus_remove_driver+0x11b/0x2a0 [ 3707.563829] pci_unregister_driver+0x2a/0x250 Introduce an error check and log the vport number and error code. On removal make sure to check VPORT_REG_NETDEV flag prior to calling unregister and free on the netdev. Add local variables for idx, vport_config and netdev for readability. (CVE-2025-22116)

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

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

  - 已解決 Linux 核心中的下列弱點：idpf: fix adapter NULL pointer dereference on reboot With SRIOV enabled, idpf ends up calling into idpf_remove() twice. First via idpf_shutdown() and then again when idpf_remove() calls into sriov_disable(), because the VF devices use the idpf driver, hence the same remove routine. When that happens, it is possible for the adapter to be NULL from the first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net/<netif>/device/sriov_numvfs reboot BUG: kernel NULL pointer dereference, address:
    0000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() call in idpf_shutdown() with idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform the bulk of the cleanup, such as stopping the init task, freeing IRQs, destroying the vports and freeing the mailbox. This avoids the calls to sriov_disable() in addition to a small netdev cleanup, and destroying workqueues, which don't seem to be required on shutdown. (CVE-2025-22065)

  - 已解決 Linux 核心中的下列弱點：idpf: convert workqueues to unbound When a workqueue is created with `WQ_UNBOUND`, its work items are served by special worker-pools, whose host workers are not bound to any specific CPU. In the default configuration (i.e. when `queue_delayed_work` and friends do not specify which CPU to run the work item on), `WQ_UNBOUND` allows the work item to be executed on any CPU in the same node of the CPU it was enqueued on. While this solution potentially sacrifices locality, it avoids contention with other processes that might dominate the CPU time of the processor the work item was scheduled on. This is not just a theoretical problem: in a particular scenario misconfigured process was hogging most of the time from CPU0, leaving less than 0.5% of its CPU time to the kworker. The IDPF workqueues that were using the kworker on CPU0 suffered large completion delays as a result, causing performance degradation, timeouts and eventual system crash. * I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`. (CVE-2024-58057)

  - 已解決 Linux 核心中的下列弱點：idpf: fix checksums set in idpf_rx_rsc() idpf_rx_rsc() uses skb_transport_offset(skb) while the transport header is not set yet. This triggers the following warning for CONFIG_DEBUG_NET=y builds.
    DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)) [ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth [ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697 [ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748) [69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261687] ? report_bug (lib/bug.c:?) [ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285) [ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309) [ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf [69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf [ 69.261712]
    __napi_poll (net/core/dev.c:7194) [ 69.261716] net_rx_action (net/core/dev.c:7265) [ 69.261718] ?
    __qdisc_run (net/sched/sch_generic.c:293) [ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288) [ 69.261726] handle_softirqs (kernel/softirq.c:561) (CVE-2025-21890)

  - 已解決 Linux 核心中的下列弱點：idpf: check error for register_netdev() on init Current init logic ignores the error code from register_netdev(), which will cause WARN_ON() on attempt to unregister it, if there was one, and there is no info for the user that the creation of the netdev failed. WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641] unregister_netdev+0x1c/0x30 [3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf] [3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739] idpf_remove+0xbf/0x780 [idpf] [3707.563769] pci_device_remove+0xab/0x1e0 [ 3707.563786] device_release_driver_internal+0x371/0x530 [3707.563803] driver_detach+0xbf/0x180 [ 3707.563816] bus_remove_driver+0x11b/0x2a0 [ 3707.563829] pci_unregister_driver+0x2a/0x250 Introduce an error check and log the vport number and error code. On removal make sure to check VPORT_REG_NETDEV flag prior to calling unregister and free on the netdev. Add local variables for idx, vport_config and netdev for readability. (CVE-2025-22116)

  - 已解決 Linux 核心中的下列弱點：idpf: fix null-ptr-deref in idpf_features_check idpf_features_check is used to validate the TX packet. skb header length is compared with the hardware supported value received from the device control plane. The value is stored in the adapter structure and to access it, vport pointer is used. During reset all the vports are released and the vport pointer that the netdev private structure points to is NULL. To avoid null-ptr-deref, store the max header length value in netdev private structure. This also helps to cache the value and avoid accessing adapter pointer in hot path. BUG: kernel NULL pointer dereference, address: 0000000000000068 ...
    RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...
    (CVE-2025-38053)

請注意，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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

  - 已解決 Linux 核心中的下列弱點：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已解決 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 核心中的下列弱點：net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - 已解決 Linux 核心中的下列弱點：RDMA/irdma: Cap MSIX used to online CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ? irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ? ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ? irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ? auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0 bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50 do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ? rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0 ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ? selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ? do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb (CVE-2023-53811)

  - 已解決 Linux 核心中的下列弱點：i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] (CVE-2024-35984)

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

遠端的 Debian 13 主機安裝了受多項漏洞影響的套件，如 dsa-6238 公告中所述。

    - ------------------------------------------------------------------------- Debian 安全諮詢 DSA-6238-1 security@debian.org https://www.debian.org/security/Salvatore Bonaccorso 2026 年 4 月 30 日 https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    套件：linux CVE ID：CVE-2024-14027 CVE-2025-21709 CVE-2025-22116 CVE-2025-22117 CVE-2025-38426 CVE-2025-38627 CVE-2025-39764 CVE-2025-40005 CVE-2025-40135 CVE-2025-40147 CVE-2025-40150 CVE-2025-40219 CVE-2025-68175 CVE-2025-68239 CVE-2025-68334 CVE-2025-68736 CVE-2025-71152 CVE-2025-71161 CVE-2025-71221 CVE-2025-71239 CVE-2025-71265 CVE-2025-71266 CVE-2025-71267 CVE-2025-71269 CVE-2026-22981 CVE-2026-22985 CVE-2026-22986 CVE-2026-22993 CVE-2026-23004 CVE-2026-23066 CVE-2026-23070 CVE-2026-23104 CVE-2026-23138 CVE-2026-23157 CVE-2026-23207 CVE-2026-23210 CVE-2026-23226 CVE-2026-23227 CVE-2026-23231 CVE-2026-23239 CVE-2026-23240 CVE-2026-23242 CVE-2026-23243 CVE-2026-23244 CVE-2026-23245 CVE-2026-23246 CVE-2026-23249 CVE-2026-23250 CVE-2026-23251 CVE-2026-23252 CVE-2026-23253 CVE-2026-23255 CVE-2026-23270 CVE-2026-23271 CVE-2026-23273 CVE-2026-23274 CVE-2026-23276 CVE-2026-23277 CVE-2026-23278 CVE-2026-23279 CVE-2026-23281 CVE-2026-23284 CVE-2026-23285 CVE-2026-23286 CVE-2026-23287 CVE-2026-23289 CVE-2026-23290 CVE-2026-23291 CVE-2026-23292 CVE-2026-23293 CVE-2026-23296 CVE-2026-23297 CVE-2026-23298 CVE-2026-23300 CVE-2026-23302 CVE-2026-23303 CVE-2026-23304 CVE-2026-23306 CVE-2026-23307 CVE-2026-23308 CVE-2026-23310 CVE-2026-23312 CVE-2026-23313 CVE-2026-23315 CVE-2026-23316 CVE-2026-23317 CVE-2026-23318 CVE-2026-23319 CVE-2026-23321 CVE-2026-23324 CVE-2026-23325 CVE-2026-23330 CVE-2026-23334 CVE-2026-23335 CVE-2026-23336 CVE-2026-23339 CVE-2026-23340 CVE-2026-23343 CVE-2026-23347 CVE-2026-23351 CVE-2026-23352 CVE-2026-23354 CVE-2026-23356 CVE-2026-23357 CVE-2026-23359 CVE-2026-23360 CVE-2026-23361 CVE-2026-23362 CVE-2026-23363 CVE-2026-23364 CVE-2026-23365 CVE-2026-23367 CVE-2026-23368 CVE-2026-23369 CVE-2026-23370 CVE-2026-23372 CVE-2026-23373 CVE-2026-23374 CVE-2026-23375 CVE-2026-23378 CVE-2026-23379 CVE-2026-23380 CVE-2026-23381 CVE-2026-23382 CVE-2026-23383 CVE-2026-23386 CVE-2026-23387 CVE-2026-23388 CVE-2026-23389 CVE-2026-23391 CVE-2026-23392 CVE-2026-23393 CVE-2026-23395 CVE-2026-23396 CVE-2026-23397 CVE-2026-23398 CVE-2026-23399 CVE-2026-23401 CVE-2026-23412 CVE-2026-23413 CVE-2026-23414 CVE-2026-23417 CVE-2026-23419 CVE-2026-23420 CVE-2026-23422 CVE-2026-23426 CVE-2026-23427 CVE-2026-23428 CVE-2026-23434 CVE-2026-23438 CVE-2026-23439 CVE-2026-23440 CVE-2026-23441 CVE-2026-23442 CVE-2026-23444 CVE-2026-23445 CVE-2026-23446 CVE-2026-23447 CVE-2026-23448 CVE-2026-23449 CVE-2026-23450 CVE-2026-23452 CVE-2026-23454 CVE-2026-23455 CVE-2026-23456 CVE-2026-23457 CVE-2026-23458 CVE-2026-23460 CVE-2026-23461 CVE-2026-23462 CVE-2026-23463 CVE-2026-23464 CVE-2026-23465 CVE-2026-23466 CVE-2026-23470 CVE-2026-23474 CVE-2026-23475 CVE-2026-31389 CVE-2026-31391 CVE-2026-31392 CVE-2026-31393 CVE-2026-31394 CVE-2026-31396 CVE-2026-31399 CVE-2026-31400 CVE-2026-31401 CVE-2026-31402 CVE-2026-31403 CVE-2026-31405 CVE-2026-31406 CVE-2026-31407 CVE-2026-31408 CVE-2026-31409 CVE-2026-31410 CVE-2026-31411 CVE-2026-31412 CVE-2026-31414 CVE-2026-31415 CVE-2026-31416 CVE-2026-31417 CVE-2026-31418 CVE-2026-31421 CVE-2026-31422 CVE-2026-31423 CVE-2026-31424 CVE-2026-31425 CVE-2026-31426 CVE-2026-31427 CVE-2026-31428 CVE-2026-31429 CVE-2026-31430 CVE-2026-31431 CVE-2026-31432 CVE-2026-31433 CVE-2026-31434 CVE-2026-31436 CVE-2026-31438 CVE-2026-31439 CVE-2026-31440 CVE-2026-31441 CVE-2026-31446 CVE-2026-31447 CVE-2026-31448 CVE-2026-31449 CVE-2026-31450 CVE-2026-31451 CVE-2026-31452 CVE-2026-31453 CVE-2026-31454 CVE-2026-31455 CVE-2026-31458 CVE-2026-31462 CVE-2026-31464 CVE-2026-31466 CVE-2026-31467 CVE-2026-31469 CVE-2026-31470 CVE-2026-31473 CVE-2026-31474 CVE-2026-31476 CVE-2026-31477 CVE-2026-31478 CVE-2026-31479 CVE-2026-31480 CVE-2026-31482 CVE-2026-31483 CVE-2026-31485 CVE-2026-31487 CVE-2026-31488 CVE-2026-31489 CVE-2026-31492 CVE-2026-31494 CVE-2026-31495 CVE-2026-31496 CVE-2026-31497 CVE-2026-31498 CVE-2026-31500 CVE-2026-31502 CVE-2026-31503 CVE-2026-31504 CVE-2026-31505 CVE-2026-31506 CVE-2026-31507 CVE-2026-31508 CVE-2026-31509 CVE-2026-31510 CVE-2026-31511 CVE-2026-31512 CVE-2026-31515 CVE-2026-31516 CVE-2026-31518 CVE-2026-31519 CVE-2026-31520 CVE-2026-31521 CVE-2026-31522 CVE-2026-31523 CVE-2026-31524 CVE-2026-31525 CVE-2026-31527 CVE-2026-31528 CVE-2026-31530 CVE-2026-31531 CVE-2026-31532 CVE-2026-31533 CVE-2026-31540 CVE-2026-31542 CVE-2026-31545 CVE-2026-31546 CVE-2026-31548 CVE-2026-31549 CVE-2026-31550 CVE-2026-31551 CVE-2026-31552 CVE-2026-31554 CVE-2026-31555 CVE-2026-31556 CVE-2026-31557 CVE-2026-31558 CVE-2026-31559 CVE-2026-31561 CVE-2026-31563 CVE-2026-31565 CVE-2026-31566 CVE-2026-31570 CVE-2026-31575 CVE-2026-31576 CVE-2026-31577 CVE-2026-31578 CVE-2026-31580 CVE-2026-31581 CVE-2026-31582 CVE-2026-31583 CVE-2026-31584 CVE-2026-31585 CVE-2026-31586 CVE-2026-31587 CVE-2026-31588 CVE-2026-31590 CVE-2026-31593 CVE-2026-31594 CVE-2026-31595 CVE-2026-31596 CVE-2026-31597 CVE-2026-31598 CVE-2026-31599 CVE-2026-31602 CVE-2026-31603 CVE-2026-31604 CVE-2026-31605 CVE-2026-31606 CVE-2026-31607 CVE-2026-31610 CVE-2026-31611 CVE-2026-31612 CVE-2026-31614 CVE-2026-31615 CVE-2026-31616 CVE-2026-31617 CVE-2026-31618 CVE-2026-31619 CVE-2026-31622 CVE-2026-31623 CVE-2026-31624 CVE-2026-31625 CVE-2026-31626 CVE-2026-31627 CVE-2026-31628 CVE-2026-31629 CVE-2026-31634 CVE-2026-31637 CVE-2026-31638 CVE-2026-31639 CVE-2026-31642 CVE-2026-31644 CVE-2026-31645 CVE-2026-31646 CVE-2026-31647 CVE-2026-31648 CVE-2026-31649 CVE-2026-31651 CVE-2026-31655 CVE-2026-31656 CVE-2026-31657 CVE-2026-31658 CVE-2026-31659 CVE-2026-31660 CVE-2026-31661 CVE-2026-31662 CVE-2026-31664 CVE-2026-31665 CVE-2026-31666 CVE-2026-31667 CVE-2026-31668 CVE-2026-31669 CVE-2026-31670 CVE-2026-31671 CVE-2026-31672 CVE-2026-31673 CVE-2026-31674 CVE-2026-31675 CVE-2026-31676 CVE-2026-31677 CVE-2026-31678 CVE-2026-31679 CVE-2026-31680 CVE-2026-31681 CVE-2026-31682 CVE-2026-31683 CVE-2026-31684 CVE-2026-31685 CVE-2026-31686 CVE-2026-31689 CVE-2026-31693 CVE-2026-31786 CVE-2026-31787 CVE-2026-31788

    在 Linux 核心中發現數個弱點，這些弱點可能會導致特權提升、拒絕服務或資訊洩漏。

    針對穩定的發行版本 (trixie)，已在第 6.12.85-1 版中修復這些問題。

    建議您升級 linux 套件。

    如需有關 linux 安全性狀態的詳細資訊，請參閱其安全追蹤頁面：
    https://security-tracker.debian.org/tracker/linux

    有關 Debian 安全公告、如何將這些更新套用至您的系統以及常見問題的詳細資訊，請參閱：https://www.debian.org/security/

    郵寄清單：debian-security-announce@lists.debian.org

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

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

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

    - net/sched：修正導致頁面快取損毀的 pedit 部分 COW (Rajat Gupta) {CVE-2026-46331}
    - eventpoll：修正ep_remove結構 eventpoll / 結構檔案 UAF （Christian Brauner） [Orabug： 39668743] {CVE-2026-46242}
    - net： skbuff：修正 pskb_carve 協助程式中缺少的 zerocopy 參照 （Minh Nguyen） [Orabug： 39656679] {CVE-2026-52943}
    - arm64： 勘誤表：緩解各種 Arm CPU 上的 TLBI 勘誤表 （Mark Rutland） [Orabug： 39548792] {CVE-2025-10263}
    - openvswitch： vport：修正釋放通道埠時的自我鎖死 （Ilya Maximets） {CVE-2026-46165}
    - iommu/amd：在並行 TLB 無效的情況下序列化序列分配 （Ankit Soni） {CVE-2026-43220}
    - usb： ulpi：修正 ulpi_register（） 錯誤路徑上的記憶體洩漏 （Felix Gu） {CVE-2026-46109}
    - smb： client：拒絕使用者空間 cifs.spnego 描述 （Asim Viladi Oglu Manizada） [Orabug： 39463671] {CVE-2026-46243}
    - net：skbuff：透過片段傳輸協助程式傳播共用片段標記 (Hyunwoo Kim) [Orabug:
    39368826,39441323] {CVE-2026-43503，CVE-2026-46300}
    - net：skbuff：在合併期間保留共用片段標記 (William Bowling) [Orabug: 39368826] {CVE-2026-46300}
    - netfilter：拒絕 nft_bitwise 中的零移位 （Kai Ma） [Orabug： 39452464] {CVE-2026-46101}
    - net： ipv6：修正 seg6 和 rpl lwtunnels 中的 NOREF dst 使用 （Andrea Mayer） [Orabug： 39452457] {CVE-2026-46099}
    - ALSA： caiaq：修正探查失敗時的 usb_dev 參照計數洩漏 （Deepanshu Kartikey） [Orabug： 39452739] {CVE-2026-46048}
    - ipv6： rpl：當重新壓縮mac_len SRH 增長時，保留餘量 （Greg Kroah-Hartman） [Orabug： 39426003] {CVE-2026-43501}
    - ALSA： caiaq：修正錯誤路徑上可能剩餘的ep1_in_urb （Takashi Iwai） [Orabug： 39452746] {CVE-2026-45992}
    - net：bonding：修復 bond_xmit_broadcast() 中的釋放後使用 (Xiang Mei) [Orabug: 39205989] {CVE-2026-31419}
    - crypto： authencesn - 在執行個體建立期間拒絕短 ahash 摘要 （Yucheng Lu） [Orabug： 39452231] {CVE-2026-46033}
    - spi：修正裝置設定失敗時的資源洩漏 （Johan Hovold） [Orabug： 39452400] {CVE-2026-46083}
    - net： qrtr： ns： 限制節點總數 （Manivannan Sadhasivam） [Orabug： 39452123] {CVE-2026-46003}
    - net： bridge：在 RCU 讀取器中使用穩定的 FDB dst 快照 （Zhengchuan Liang） [Orabug： 39452411] {CVE-2026-46086}
    - net： qrtr： ns： 限制查詢的最大次數（Manivannan Sadhasivam） [Orabug: 39452207] {CVE-2026-46026}
    - net： qrtr： ns：限制每個節點的最大伺服器註冊數量（Manivannan Sadhasivam） [Orabug: 39410851] {CVE-2026-43491}
    - RDMA/mana_ib：停用 RSS QP 銷毀的 RX 轉向 （Long Li） [Orabug： 39452406] {CVE-2026-46084}
    - media： rc： igorplugusb：注意相干性規則 （Oliver Neukum） [Orabug： 39452432] {CVE-2026-46091}
    - wifi： mwifiex：修正 mwifiex_adapter_cleanup（） 中的釋放後使用 （Daniel Hodges） [Orabug： 39452343] {CVE-2026-46069}
    - thermal： core：修正熱區域調速器清理問題 （Rafael J. Wysocki） [Orabug： 39452186] {CVE-2026-46021}
    - smb：client：在 cifsacl 中重寫 DACL 之前先驗證整個 DACL (Michael Bommarito) [Orabug:
    39300611] {CVE-2026-31709}
    - scsi：sd：修正 device_add（&disk_dev） 失敗時遺失的 put_disk（） （Yang Xiuwei） [Orabug： 39452100] {CVE-2026-45997}
    - rtmutex：在 remove_waiter() 中使用 waiter::task 而不是 current (Keenan Dong) [Orabug: 39425998] {CVE-2026-43499}
    - ceph：只有 d_add（） 負 dentry 未雜湊時 （Max Kellermann） [Orabug： 39452291] {CVE-2026-46052}
    - dm mirror：修正 create_dirty_log（） 中的整數溢位 （Junrui Luo） [Orabug： 39452196] {CVE-2026-46023}
    - 藍牙：hci_event：修正 SSP 通行金鑰處理常式中潛在的 UAF (Shuvam Pandey) [Orabug: 39452304] {CVE-2026-46056}
    - tcp：接聽程式遷移後呼叫 sk_data_ready（） （Zhenzhong Wu） [Orabug： 39452159] {CVE-2026-46015}
    - inotify：修正 fsnotify_add_inode_mark_locked（） 失敗時的監視計數洩漏 （Chia-Ming Chang） [Orabug：
    39452250] {CVE-2026-46040}
    - md/raid5：在存取日誌中繼資料之前驗證負載大小 （Junrui Luo） [Orabug： 39452349] {CVE-2026-46070}
    - md/raid5：修正 retry_aligned_read（） 中的軟鎖定 （Chia-Ming Chang） [Orabug： 39452287] {CVE-2026-46051}
    - ext4：修正 ext4_xattr_inode_dec_ref_all（） 中缺少的 brelse（） （Sohei Koyama） [Orabug： 39452269] {CVE-2026-46046}
    - ext4：修正 check_xattrs（） 中的邊界檢查以防止越界存取 （Deepanshu Kartikey） [Orabug：
    39452442] {CVE-2026-46094}
    - io_uring/poll：修正喚醒爭用時缺少 EOF 的 multishot recv （Jens Axboe） {CVE-2026-23473}
    - KVM： nSVM： 如果未處理的 VMMCALL 未被 L1 攔截，則引發 #UD （Kevin Cheng） [Orabug： 39452372] {CVE-2026-46076}
    - KVM： SVM：如果是 EFER，則為 INVLPGA 注入 #UD。SVME=0 （Kevin Cheng） [Orabug： 39452394] {CVE-2026-46082}
    - KVM： nSVM：在 L2 的 VMRUN 之後，將中斷影子同步到快取的 vmcb12 （Yosry Ahmed） [Orabug： 39452061] {CVE-2026-45987}
    - xfs：修正 xfs_alloc_buftarg（） 中的資源洩漏 （Haoxiang Li） [Orabug： 39452131] {CVE-2026-46005}
    - libceph：防止 ceph_handle_auth_reply（） 中潛在的 null-ptr-deref （Raphael Zimmer） [Orabug：
    39452201] {CVE-2026-46024}
    - ipv4： icmp：使用 icmp_pointers 之前先驗證回覆類型 （Ruide Cao） [Orabug： 39452243] {CVE-2026-46037}
    - RDMA/rxe：在 rxe_rcv 中的 payload_size（） 之前驗證 pad 和 ICRC （Hkbinbin） [Orabug： 39452259] {CVE-2026-46043}
    - net： qrtr： ns： 在 ctrl_cmd_bye（） 期間釋放節點 （Manivannan Sadhasivam） [Orabug： 39452246] {CVE-2026-46038}
    - rxrpc： 修正 rxkad 加密不對齊處理 （David Howells） [Orabug： 39452728] {CVE-2026-46085}
    - ALSA： caiaq： 正確處理探查錯誤 （Takashi Iwai） [Orabug： 39452126] {CVE-2026-46004}
    - rbd：修正 device_add_disk（） 失敗時的 null-ptr-deref （Dawei Feng） [Orabug： 39452385] {CVE-2026-46079}
    - md/raid10：修正帶有檢查操作和 nowait 要求的鎖死 （Josh Hunt） [Orabug： 39452284] {CVE-2026-46050}
    - jbd2：修正 jbd2_journal_cancel_revoke（） 中的鎖死 （Zhang Yi） [Orabug： 39452318] {CVE-2026-46061}
    - erofs：修正尾隨 dirents 的越界 nameoff 處理 （Gao Xiang） [Orabug： 39452380] {CVE-2026-46078}
    - ALSA： ctxfi：新增 S/PDIF 預設 RSR 的後援 （Harin Lee） [Orabug： 39452280] {CVE-2026-46049}
    - ext2：拒絕 ext2_iget（） 中具有零i_nlink和有效模式的 inode （Vasiliy Kovalev） [Orabug： 39452119] {CVE-2026-46002}
    - net： qrtr： ns： 修正驅動程式 remove（） 中的釋放後使用 （Manivannan Sadhasivam） [Orabug： 39452274] {CVE-2026-46047}
    - net： strparser：修正 strp_abort_strp（） 中的skb_head洩露 （Luxiao Xu） [Orabug： 39452468] {CVE-2026-46102}
    - ALSA： control：在 snd_ctl_elem_init_enum_names（） 中 strnlen（） 之前驗證buf_len （Ziqing Chen） [Orabug： 39452416] {CVE-2026-46088}
    - crypto： pcrypt - 修正 MAY_BACKLOG 要求的處理 （Herbert Xu） [Orabug： 39410863] {CVE-2026-43493}
    - wifi： rtw88：檢查 PCI 上游橋接器是否存在 （Fedor Pchelkin） [Orabug： 39452437] {CVE-2026-46092}
    - zram：不要忘記部分捨棄請求的 endio （Sergey Senozhatsky） [Orabug： 39452420] {CVE-2026-46089}
    - ocfs2：在 dio 完成時拆分交易以避免信用耗盡 （Heming Zhao） [Orabug： 39452388] {CVE-2026-46080}
    - drm/amdgpu： 限制 BO 清單項目計數以防止資源耗盡 （Jesse Zhang） [Orabug： 39167551] {CVE-2026-23468}
    - padata：一勞永逸地修正 pd UAF （Herbert Xu） [Orabug： 38335055] {CVE-2025-38584}
    - drm/nouveau：修正 pushbuf 重新定位邊界檢查中的 u32 溢位 （Greg Kroah-Hartman） [Orabug： 39452133] {CVE-2026-46006}
    - ALSA： usb-audio：停止剖析 MAX_NR_RATES 的 UAC2 速率 （Cassio Gabriel） [Orabug： 39452170] {CVE-2026-46018}
    - drivers/xen/sys-hypervisor.c 中的緩衝區溢位 （Juergen Gross） [Orabug： 39305898] {CVE-2026-31786}
    - xen/privcmd：透過 VMA 分割修正雙重釋放 （Juergen Gross） [Orabug： 39305908] {CVE-2026-31787}
    - rxrpc： 修正非 XDR 金鑰準備中缺少的票證長度驗證 （Anderson Nascimento） [Orabug：
    39300563] {CVE-2026-31696}
    - crypto： ccp：如果 PSP 命令失敗，請勿嘗試將 ID 複製到使用者空間 （Sean Christopherson） {CVE-2026-31697}
    - crypto： ccp：如果 PSP 命令失敗，請勿嘗試將 PDH cert 複製到使用者空間 （Sean Christopherson） {CVE-2026-31698}
    - crypto： ccp：如果 PSP 命令失敗，請勿嘗試將 CSR 複製到使用者空間 （Sean Christopherson） {CVE-2026-31699}
    - net/packet：修正 tpacket_snd（） 中 mmap'd vnet_hdr 上的 TOCTOU 爭用 （Bingquan Chen） {CVE-2026-31700}
    - ALSA： caiaq：在 create_card（） 中參照 USB 裝置 （Berk Cem Goksel） [Orabug： 39300586] {CVE-2026-31701}
    - smb： client：修正smb2_ioctl_query_info QUERY_INFO路徑中的 OOB 讀取 （Michael Bommarito） [Orabug：
    39300607] {CVE-2026-31708}
    - smb： client：在讀取模式位元之前需要完整的 NFS 模式 SID （Michael Bommarito） [Orabug： 39343707] {CVE-2026-43350}
    - fuse：拒絕頁面快取中的過大內容 （Samuel Page） [Orabug： 39300556] {CVE-2026-31694}
    - mm/pagewalk：修正並行分割和重新fault之間的爭用 （Max Boone） [Orabug： 39250782] {CVE-2026-31456}
    - wifi： mac80211：ieee80211_tx_prepare_skb（） 失敗時始終釋放 skb （Felix Fietkau） [Orabug： 39167472] {CVE-2026-23444}
    - mm/userfaultfd：修正 hugetlb 錯誤互斥雜湊計算 （Jianhui Zhou） [Orabug： 39273453] {CVE-2026-31575}
    - ipv6：在 SRv6 路徑中新增 idev 的 NULL 檢查 （Heminhong） [Orabug： 39167467] {CVE-2026-23442}
    - ocfs2：修正 ocfs2_write_end_inline 中的越界寫入 （Joseph Qi） [Orabug： 39331090] {CVE-2026-43075}
    - ocfs2：在 inode 讀取期間驗證內嵌資料i_size （Deepanshu Kartikey） [Orabug： 39331097] {CVE-2026-43076}
    - media： as102：修正裝置在 as102_usb_probe（） 中註冊後不會釋放記憶體的問題 （Jeongjun Park） [Orabug： 39273467] {CVE-2026-31578}
    - bcache：修正 cached_dev.sb_bio 釋放後使用和崩潰 （Mingzhe Zou） [Orabug： 39273481] {CVE-2026-31580}
    - ALSA： 6fire：修正中斷連接時的釋放後使用 （Berk Cem Goksel） [Orabug： 39273486] {CVE-2026-31581}
    - media： em28xx：修正 em28xx_v4l2_open（） 中的釋放後使用 （Abhishek Kumar） [Orabug： 39273493] {CVE-2026-31583}
    - mm： blk-cgroup：修正 cgwb_release_workfn（） 中的釋放後使用 （Breno Leitao） [Orabug： 39273507] {CVE-2026-31586}
    - KVM：x86：使用 MMIO 片段中的暫存欄位來保存小寫入值 （Sean Christopherson） [Orabug：
    39273521] {CVE-2026-31588}
    - x86-64：重新命名具有誤導性名稱的「__copy_user_nocache（）」函式 （Linus Torvalds） [Orabug： 39323162] {CVE-2026-43073}
    - kernel：對於 dup_mmap() 失敗和 uprobe 註冊要更加小心 (Liam R. Howlett) {CVE-2025-21709}
    - gpiolib：修正 gdev->srcu 的爭用情形 （Pawel Narewski） [Orabug： 38887677] {CVE-2026-22986}
    - KVM： SEV：對 KVM_MEMORY_ENCRYPT_REG_REGION 的大尺寸刪除 WARN （Sean Christopherson） [Orabug：
    39273529] {CVE-2026-31590}
    - KVM： SEV：拒絕嘗試同步已啟動/加密 vCPU 的 VMSA （Sean Christopherson） [Orabug： 39273553] {CVE-2026-31593}
    - ocfs2：處理 ocfs2_group_extend 中無效的 dinode （Zhengyuan Huang） [Orabug： 39273569] {CVE-2026-31596}
    - ocfs2：修正 ocfs2_fault（） 中VM_FAULT_RETRY時的釋放後使用 （Tejas Bharambe） [Orabug： 39273578] {CVE-2026-31597}
    - ocfs2：修正取消連結和dio_end_io_write之間可能的鎖死 （Joseph Qi） [Orabug： 39273586] {CVE-2026-31598}
    - dcache：將儲存桶的最小數量限制為兩個 （Zhihao Cheng） [Orabug： 39323133] {CVE-2026-43071}
    - ALSA： ctxfi：將 PTP 限制為單一頁面 （Harin Lee） [Orabug： 39273608] {CVE-2026-31602}
    - wifi： rtw88：修正探查失敗時的裝置洩漏 （Johan Hovold） [Orabug： 39273620] {CVE-2026-31604}

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

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

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

  - 已解決 Linux 核心中的下列弱點：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已解決 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 核心中的下列弱點：net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000)
    - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue:
    smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP:
    0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08:
    ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ?
    __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ?
    __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ?
    __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr:
    create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration. (CVE-2023-53382)

  - 已解決 Linux 核心中的下列弱點：RDMA/irdma: Cap MSIX used to online CPUs + 1 The irdma driver can use a maximum number of msix vectors equal to num_online_cpus() + 1 and the kernel warning stack below is shown if that number is exceeded. The kernel throws a warning as the driver tries to update the affinity hint with a CPU mask greater than the max CPU IDs. Fix this by capping the MSIX vectors to num_online_cpus() + 1. WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma] Call Trace:
    irdma_rt_init_hw+0xa62/0x1290 [irdma] ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma] ?
    __is_kernel_percpu_address+0x63/0x310 ? rcu_read_lock_held_common+0xe/0xb0 ? irdma_lan_unregister_qset+0x280/0x280 [irdma] ? irdma_request_reset+0x80/0x80 [irdma] ? ice_get_qos_params+0x84/0x390 [ice] irdma_probe+0xa40/0xfc0 [irdma] ? rcu_read_lock_bh_held+0xd0/0xd0 ? irdma_remove+0x140/0x140 [irdma] ? rcu_read_lock_sched_held+0x62/0xe0 ? down_write+0x187/0x3d0 ? auxiliary_match_id+0xf0/0x1a0 ? irdma_remove+0x140/0x140 [irdma] auxiliary_bus_probe+0xa6/0x100
    __driver_probe_device+0x4a4/0xd50 ? __device_attach_driver+0x2c0/0x2c0 driver_probe_device+0x4a/0x110
    __driver_attach+0x1aa/0x350 bus_for_each_dev+0x11d/0x1b0 ? subsys_dev_iter_init+0xe0/0xe0 bus_add_driver+0x3b1/0x610 driver_register+0x18e/0x410 ? 0xffffffffc0b88000 irdma_init_module+0x50/0xaa [irdma] do_one_initcall+0x103/0x5f0 ? perf_trace_initcall_level+0x420/0x420 ? do_init_module+0x4e/0x700 ?
    __kasan_kmalloc+0x7d/0xa0 ? kmem_cache_alloc_trace+0x188/0x2b0 ? kasan_unpoison+0x21/0x50 do_init_module+0x1d1/0x700 load_module+0x3867/0x5260 ? layout_and_allocate+0x3990/0x3990 ? rcu_read_lock_held_common+0xe/0xb0 ? rcu_read_lock_sched_held+0x62/0xe0 ? rcu_read_lock_bh_held+0xd0/0xd0 ? __vmalloc_node_range+0x46b/0x890 ? lock_release+0x5c8/0xba0 ? alloc_vm_area+0x120/0x120 ? selinux_kernel_module_from_file+0x2a5/0x300 ? __inode_security_revalidate+0xf0/0xf0 ?
    __do_sys_init_module+0x1db/0x260 __do_sys_init_module+0x1db/0x260 ? load_module+0x5260/0x5260 ? do_syscall_64+0x22/0x450 do_syscall_64+0xa5/0x450 entry_SYSCALL_64_after_hwframe+0x66/0xdb (CVE-2023-53811)

  - 已解決 Linux 核心中的下列弱點：i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] (CVE-2024-35984)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
247702	Linux Distros 未修補弱點：CVE-2025-22116	Nessus	Misc.	2025/8/10	2026/8/21	medium
249174	CentOS 9: kernel-5.14.0-604.el9	Nessus	CentOS Local Security Checks	2025/8/12	2025/9/24	medium
340680	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS：Linux 核心（Raspberry Pi）弱點（USN-8665-1）	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/8/27	high
240657	Ubuntu 25.04：Linux 核心弱點 (USN-7594-1)	Nessus	Ubuntu Local Security Checks	2025/6/26	2026/1/6	high
360066	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1783091784）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/18	medium
311299	Debian dsa-6238 ： ata-modules-6.12.74+deb13+1-armmp-di - security update	Nessus	Debian Local Security Checks	2026/4/30	2026/5/8	high
325292	Oracle Linux 10 / 9：Unbreakable Enterprise 核心 (ELSA-2026-50372)	Nessus	Oracle Linux Local Security Checks	2026/7/6	2026/7/8	high
360243	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1783091784）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/18	medium

偵測

搜尋 Plugin

medium

medium

high

high

medium

high

high

medium