The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1791780738 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in     shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure     that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs     don't hold their own references to pages that are mirrored over, so failing to notify them can lead to     page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b     (khugepaged: add support of collapse for tmpfs/shmem pages), but most of the security impact of this     only came in commit 27e1f8273113 (khugepaged: enable collapse pmd for pte-mapped THP), which actually     omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
    (CVE-2022-48991)

  - In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after     suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip     link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set     eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138     xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac
    __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64     do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely     (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets     up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down()     and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to     xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the     future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the     missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if     netif_running(). However, this should not make any functional difference since the refill work should only     be active if the network interface is actually up. (CVE-2022-49687)

  - In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix repeated calls to     sock_put() when msg has more_data In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
    __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data, sock_put() will be called multiple     times. We should reset the eval variable to __SK_NONE every time more_data starts. This causes: IPv4:
    Attempt to release TCP socket in state 1 00000000b4c925d7 ------------[ cut here ]------------ refcount_t:
    addition on 0; use-after-free. WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25     refcount_warn_saturate+0x7d/0x110 Modules linked in: CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded     Not tainted 6.0.0 #1 Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK>
    __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320     tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640     tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0     tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70
    __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0
    __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd     (CVE-2022-50536)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer     overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid     req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free     in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be     called multiple times on same ring, if system is under stress and got memory allocation error. Ring     pointer was used as an indicator of failure, but this is not correct since only ring data is     allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error     code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.
    (CVE-2023-52664)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Ubuntu 22.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8876-1 advisory.

    It was discovered that the i.MX clock driver in the Linux kernel did not properly handle certain memory     allocation failure conditions, leading to a null pointer dereference vulnerability. A local attacker could     possibly use this to cause a denial of service (system crash). (CVE-2022-3114)

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - ARM32 architecture;

    - ARM64 architecture;

    - MIPS architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Block layer subsystem;

    - Cryptographic API;

    - ACPI drivers;

    - Android drivers;

    - Serial ATA and Parallel ATA drivers;

    - Drivers core;

    - DRBD Distributed Replicated Block Device drivers;

    - Rados block device (RBD) driver;

    - Bluetooth drivers;

    - Cdrom driver;

    - Character device driver;

    - Hardware random number generator core;

    - TPM device driver;

    - Data acquisition framework and drivers;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - DAX dirext access to differentiated memory framework;

    - DMA engine subsystem;

    - FireWire subsystem;

    - Arm Firmware Framework for ARMv8-A(FFA);

    - Intel Stratix 10 firmware drivers;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - Hardware monitoring drivers;

    - Intel Trace Hub HW tracing drivers;

    - I2C subsystem;

    - IIO subsystem;

    - IIO ADC drivers;

    - IIO Magnetometer sensors drivers;

    - InfiniBand drivers;

    - Input Device core drivers;

    - Input Device (Miscellaneous) drivers;

    - Input Device (Mouse) drivers;

    - IOMMU subsystem;

    - IRQ chip drivers;

    - LED subsystem;

    - Multiple devices driver;

    - Media drivers;

    - MemoryStick subsystem;

    - Multifunction device drivers;

    - Fastrpc Driver;

    - MTD block device drivers;

    - Network drivers;

    - Mellanox network drivers;

    - Microsoft Azure Network Adapter (MANA) driver;

    - Texas Instruments network drivers;

    - MediaTek network drivers;

    - NTB driver;

    - NVDIMM (Non-Volatile Memory Device) drivers;

    - NVME drivers;

    - PCI subsystem;

    - Pin controllers subsystem;

    - Generic PM domains;

    - Power supply drivers;

    - Voltage and Current Regulator drivers;

    - Reset controller framework;

    - S/390 drivers;

    - SCSI subsystem;

    - SLIMbus drivers;

    - SPI subsystem;

    - Media staging drivers;

    - Media Oriented Systems Transport (MOST) driver;

    - NVIDIA Tegra embedded controller (NVEC) staging driver;

    - Realtek RTL8723BS SDIO drivers;

    - TCM subsystem;

    - Trusted Execution Environment drivers;

    - Thermal drivers;

    - Thunderbolt and USB4 drivers;

    - USB DSL drivers;

    - Cadence USB3 driver;

    - ULPI bus;

    - DesignWare USB3 driver;

    - USB Gadget drivers;

    - USB Host Controller drivers;

    - USB ChaosKey driver;

    - Siemens ID Mouse USB driver;

    - IOWarrior USB driver;

    - LD Didactic USB driver;

    - LEGO USB Tower driver;

    - USS720 USB parallel port adapter driver;

    - MediaTek USB3 DRD driver;

    - USB Serial drivers;

    - USB Type-C Port Controller Manager driver;

    - USB Type-C Connector System Software Interface driver;

    - USB over IP driver;

    - vDPA drivers;

    - VFIO drivers;

    - Virtio Host (VHOST) subsystem;

    - Framebuffer layer;

    - Watchdog drivers;

    - Xen hypervisor drivers;

    - AFS file system;

    - File systems infrastructure;

    - BTRFS file system;

    - Ceph distributed file system;

    - EROFS file system;

    - exFAT file system;

    - Ext4 file system;

    - F2FS file system;

    - FUSE (File system in Userspace);

    - HFS file system;

    - HFS+ file system;

    - Journaling layer for block devices (JBD2);

    - Network file system (NFS) client;

    - Network file system (NFS) server daemon;

    - NILFS2 file system;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - Proc file system;

    - SMB network file system;

    - UDF file system;

    - XFS file system;

    - Software nodes and device properties;

    - Glob pattern matching library;

    - Netfilter;

    - Socket messages infrastructure;

    - Network sockets;

    - Memory Management;

    - Network traffic control;

    - IPv6 networking;

    - Bluetooth subsystem;

    - Networking core;

    - IP tunnels definitions;

    - IPv4 networking;

    - SCTP protocol;

    - XFRM subsystem;

    - io_uring subsystem;

    - IPC subsystem;

    - Audit subsystem;

    - BPF subsystem;

    - Control group (cgroup);

    - Kernel CPU control infrastructure;

    - Kernel exit() syscall;

    - Kernel futex primitives;

    - Scheduler infrastructure;

    - Signal handling mechanism;

    - Timer subsystem;

    - Tracing infrastructure;

    - Cryptographic library;

    - Debug objects infrastructure;

    - Resizable hashtable library;

    - Memory management;

    - 6LoWPAN network protocol;

    - IEEE 802 network protocols;

    - 9P file system network protocol;

    - Asynchronous Transfer Mode (ATM) subsystem;

    - B.A.T.M.A.N. meshing protocol;

    - Ethernet bridge;

    - CAN network layer;

    - Ceph Core library;

    - HSR network protocol;

    - IEEE802154.4 network protocol;

    - IFE protocol;

    - IUCV driver;

    - KCM (Kernel Connection Multiplexor) sockets driver;

    - Logical Link layer;

    - MAC80211 subsystem;

    - IEEE 802.15.4 subsystem;

    - Management Component Transport Protocol (MCTP);

    - MultiProtocol Label Switching driver;

    - NetLabel subsystem;

    - Open vSwitch;

    - Packet sockets;

    - Phonet protocol;

    - Packet sampling (psample);

    - Qualcomm IPC Router (QRTR);

    - RDS protocol;

    - SMC sockets;

    - Sun RPC protocol;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - VMware vSockets driver;

    - Wireless networking;

    - X.25 network layer;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - Key management;

    - Apple Onboard Audio ALSA driver;

    - ALSA framework;

    - Generic PCM loopback sound driver;

    - FireWire sound drivers;

    - ESS Solo-1 ALSA driver;

    - HD-audio driver;

    - SoC Audio for Freescale CPUs drivers;

    - NVIDIA Tegra ASoC drivers;

    - USB sound devices;

    - Perf tools;

    - KVM subsystem; (CVE-2023-54125, CVE-2023-54271, CVE-2025-22026, CVE-2025-23131, CVE-2025-39863,     CVE-2025-39929, CVE-2025-39931, CVE-2026-23364, CVE-2026-31449, CVE-2026-31451, CVE-2026-31610,     CVE-2026-31700, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-31715,     CVE-2026-43064, CVE-2026-43216, CVE-2026-43219, CVE-2026-43350, CVE-2026-43355, CVE-2026-43491,     CVE-2026-43492, CVE-2026-45850, CVE-2026-45930, CVE-2026-45991, CVE-2026-45999, CVE-2026-46003,     CVE-2026-46021, CVE-2026-46026, CVE-2026-46038, CVE-2026-46052, CVE-2026-46056, CVE-2026-46065,     CVE-2026-46069, CVE-2026-46078, CVE-2026-46086, CVE-2026-46090, CVE-2026-46091, CVE-2026-46092,     CVE-2026-46103, CVE-2026-46116, CVE-2026-46159, CVE-2026-46160, CVE-2026-46169, CVE-2026-46180,     CVE-2026-46191, CVE-2026-46193, CVE-2026-46196, CVE-2026-46208, CVE-2026-46252, CVE-2026-46291,     CVE-2026-46292, CVE-2026-46299, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-52909,     CVE-2026-52910, CVE-2026-52913, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52927,     CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52933, CVE-2026-52934, CVE-2026-52935,     CVE-2026-52939, CVE-2026-52942, CVE-2026-52943, CVE-2026-52947, CVE-2026-52948, CVE-2026-52977,     CVE-2026-53080, CVE-2026-53090, CVE-2026-53133, CVE-2026-53134, CVE-2026-53135, CVE-2026-53136,     CVE-2026-53137, CVE-2026-53138, CVE-2026-53139, CVE-2026-53146, CVE-2026-53148, CVE-2026-53149,     CVE-2026-53150, CVE-2026-53157, CVE-2026-53158, CVE-2026-53159, CVE-2026-53161, CVE-2026-53167,     CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53189, CVE-2026-53194, CVE-2026-53195,     CVE-2026-53196, CVE-2026-53199, CVE-2026-53208, CVE-2026-53213, CVE-2026-53217, CVE-2026-53218,     CVE-2026-53219, CVE-2026-53223, CVE-2026-53227, CVE-2026-53238, CVE-2026-53239, CVE-2026-53245,     CVE-2026-53249, CVE-2026-53252, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256,     CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53266, CVE-2026-53268, CVE-2026-53269,     CVE-2026-53270, CVE-2026-53273, CVE-2026-53275, CVE-2026-53325, CVE-2026-53332, CVE-2026-53392,     CVE-2026-53393, CVE-2026-53399, CVE-2026-53400, CVE-2026-53402, CVE-2026-63806, CVE-2026-63810,     CVE-2026-63815, CVE-2026-63817, CVE-2026-63818, CVE-2026-63827, CVE-2026-63828, CVE-2026-63829,     CVE-2026-63830, CVE-2026-64187, CVE-2026-64189, CVE-2026-64206, CVE-2026-64266, CVE-2026-64268,     CVE-2026-64269, CVE-2026-64271, CVE-2026-64273, CVE-2026-64274, CVE-2026-64275, CVE-2026-64276,     CVE-2026-64277, CVE-2026-64279, CVE-2026-64296, CVE-2026-64298, CVE-2026-64299, CVE-2026-64301,     CVE-2026-64303, CVE-2026-64304, CVE-2026-64306, CVE-2026-64312, CVE-2026-64313, CVE-2026-64315,     CVE-2026-64316, CVE-2026-64317, CVE-2026-64318, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324,     CVE-2026-64329, CVE-2026-64330, CVE-2026-64331, CVE-2026-64332, CVE-2026-64333, CVE-2026-64334,     CVE-2026-64335, CVE-2026-64336, CVE-2026-64337, CVE-2026-64338, CVE-2026-64340, CVE-2026-64342,     CVE-2026-64343, CVE-2026-64344, CVE-2026-64346, CVE-2026-64347, CVE-2026-64350, CVE-2026-64351,     CVE-2026-64352, CVE-2026-64355, CVE-2026-64359, CVE-2026-64360, CVE-2026-64361, CVE-2026-64362,     CVE-2026-64363, CVE-2026-64364, CVE-2026-64370, CVE-2026-64371, CVE-2026-64372, CVE-2026-64373,     CVE-2026-64374, CVE-2026-64375, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64390,     CVE-2026-64401, CVE-2026-64403, CVE-2026-64408, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413,     CVE-2026-64420, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64428, CVE-2026-64429,     CVE-2026-64430, CVE-2026-64432, CVE-2026-64435, CVE-2026-64436, CVE-2026-64438, CVE-2026-64440,     CVE-2026-64441, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64445, CVE-2026-64446,     CVE-2026-64448, CVE-2026-64450, CVE-2026-64452, CVE-2026-64454, CVE-2026-64455, CVE-2026-64456,     CVE-2026-64461, CVE-2026-64462, CVE-2026-64465, CVE-2026-64468, CVE-2026-64469, CVE-2026-64470,     CVE-2026-64471, CVE-2026-64475, CVE-2026-64478, CVE-2026-64483, CVE-2026-64484, CVE-2026-64487,     CVE-2026-64488, CVE-2026-64494, CVE-2026-64495, CVE-2026-64496, CVE-2026-64497, CVE-2026-64500,     CVE-2026-64503, CVE-2026-64504, CVE-2026-64505, CVE-2026-64510, CVE-2026-64512, CVE-2026-64514,     CVE-2026-64530, CVE-2026-64532, CVE-2026-64533, CVE-2026-64534, CVE-2026-64535, CVE-2026-64536,     CVE-2026-64537, CVE-2026-64538, CVE-2026-64540, CVE-2026-64541, CVE-2026-64543, CVE-2026-64544,     CVE-2026-64545, CVE-2026-64546, CVE-2026-64547, CVE-2026-64548, CVE-2026-64549, CVE-2026-64550,     CVE-2026-64551, CVE-2026-64553, CVE-2026-64554, CVE-2026-64560, CVE-2026-64562, CVE-2026-64563,     CVE-2026-64564, CVE-2026-64565, CVE-2026-64567, CVE-2026-64569, CVE-2026-64571, CVE-2026-64572,     CVE-2026-64573, CVE-2026-64576, CVE-2026-64578, CVE-2026-64579, CVE-2026-64582, CVE-2026-64583,     CVE-2026-64584, CVE-2026-64593, CVE-2026-64594, CVE-2026-64599, CVE-2026-64600, CVE-2026-64602,     CVE-2026-64604, CVE-2026-68088, CVE-2026-68090, CVE-2026-68091, CVE-2026-68104, CVE-2026-68106,     CVE-2026-68111, CVE-2026-68115, CVE-2026-68117, CVE-2026-68121, CVE-2026-68123, CVE-2026-68125,     CVE-2026-68127, CVE-2026-68129, CVE-2026-68131, CVE-2026-68135, CVE-2026-68137, CVE-2026-68140,     CVE-2026-68141, CVE-2026-68142, CVE-2026-68143, CVE-2026-68144, CVE-2026-68151, CVE-2026-68153,     CVE-2026-68154, CVE-2026-68155, CVE-2026-68156, CVE-2026-68157, CVE-2026-68158, CVE-2026-68160,     CVE-2026-68175, CVE-2026-68176, CVE-2026-68180, CVE-2026-68182, CVE-2026-68183, CVE-2026-68184,     CVE-2026-68186, CVE-2026-68187, CVE-2026-68188, CVE-2026-68190, CVE-2026-68192, CVE-2026-68195,     CVE-2026-68196, CVE-2026-68197, CVE-2026-68199, CVE-2026-68204, CVE-2026-68209, CVE-2026-68212,     CVE-2026-68213, CVE-2026-68214, CVE-2026-68215, CVE-2026-68216, CVE-2026-68217, CVE-2026-68218,     CVE-2026-68222, CVE-2026-68223, CVE-2026-68226, CVE-2026-68227, CVE-2026-68229, CVE-2026-68231,     CVE-2026-68234, CVE-2026-68243, CVE-2026-68244, CVE-2026-68248, CVE-2026-68249, CVE-2026-68250,     CVE-2026-68284, CVE-2026-68294, CVE-2026-68297, CVE-2026-68299, CVE-2026-68300, CVE-2026-68301,     CVE-2026-68304, CVE-2026-68309, CVE-2026-68313, CVE-2026-68315, CVE-2026-68320, CVE-2026-68322,     CVE-2026-68324, CVE-2026-68325, CVE-2026-68326, CVE-2026-68327, CVE-2026-68328, CVE-2026-68331,     CVE-2026-68333, CVE-2026-68335, CVE-2026-68338, CVE-2026-68340, CVE-2026-68349, CVE-2026-68350,     CVE-2026-68351, CVE-2026-68352, CVE-2026-68353, CVE-2026-68354, CVE-2026-68355, CVE-2026-68357,     CVE-2026-68360, CVE-2026-68361, CVE-2026-68363, CVE-2026-68365, CVE-2026-68366, CVE-2026-68368,     CVE-2026-68369, CVE-2026-68370, CVE-2026-68373, CVE-2026-68376, CVE-2026-68377, CVE-2026-68388,     CVE-2026-68395, CVE-2026-68397, CVE-2026-68398, CVE-2026-68402, CVE-2026-68403, CVE-2026-68405,     CVE-2026-68406, CVE-2026-68410, CVE-2026-68411, CVE-2026-68413, CVE-2026-68414, CVE-2026-68417,     CVE-2026-68422, CVE-2026-68425, CVE-2026-68428, CVE-2026-68430, CVE-2026-68432, CVE-2026-68433,     CVE-2026-68444, CVE-2026-68446, CVE-2026-68449, CVE-2026-68450, CVE-2026-68451, CVE-2026-68452,     CVE-2026-68456, CVE-2026-68459, CVE-2026-68460, CVE-2026-68461, CVE-2026-68466, CVE-2026-68467,     CVE-2026-68469, CVE-2026-68474, CVE-2026-68475, CVE-2026-68477, CVE-2026-68478, CVE-2026-68479,     CVE-2026-68480, CVE-2026-72004, CVE-2026-72005, CVE-2026-72010, CVE-2026-72013, CVE-2026-72014,     CVE-2026-72019, CVE-2026-72020, CVE-2026-72021, CVE-2026-72022, CVE-2026-72024, CVE-2026-72025,     CVE-2026-72033, CVE-2026-72036, CVE-2026-72038, CVE-2026-72039, CVE-2026-72047, CVE-2026-72048,     CVE-2026-72049, CVE-2026-72052, CVE-2026-72054, CVE-2026-72055, CVE-2026-72056, CVE-2026-72061,     CVE-2026-72066, CVE-2026-72067, CVE-2026-72068, CVE-2026-72074, CVE-2026-72076, CVE-2026-72078,     CVE-2026-72079, CVE-2026-72081, CVE-2026-72082, CVE-2026-72083, CVE-2026-72084, CVE-2026-72085,     CVE-2026-72086, CVE-2026-72088, CVE-2026-72102, CVE-2026-72105, CVE-2026-72107, CVE-2026-72108,     CVE-2026-72109, CVE-2026-72113, CVE-2026-72114, CVE-2026-72115, CVE-2026-72116, CVE-2026-72117,     CVE-2026-72118, CVE-2026-72119, CVE-2026-72120, CVE-2026-72121, CVE-2026-72122, CVE-2026-72123,     CVE-2026-72124, CVE-2026-72125, CVE-2026-72126, CVE-2026-72129, CVE-2026-72133, CVE-2026-72135,     CVE-2026-72136, CVE-2026-72138, CVE-2026-72140, CVE-2026-72146, CVE-2026-72153, CVE-2026-72159,     CVE-2026-72160, CVE-2026-72163, CVE-2026-72164, CVE-2026-72165, CVE-2026-72166, CVE-2026-72167,     CVE-2026-72171, CVE-2026-72181, CVE-2026-72182, CVE-2026-72192, CVE-2026-72193, CVE-2026-72194,     CVE-2026-72195, CVE-2026-72197, CVE-2026-72215, CVE-2026-72218, CVE-2026-72219, CVE-2026-72223,     CVE-2026-72224, CVE-2026-72225, CVE-2026-72226, CVE-2026-72228, CVE-2026-72229, CVE-2026-72230,     CVE-2026-72231, CVE-2026-72232, CVE-2026-72233, CVE-2026-72234, CVE-2026-72235, CVE-2026-72238,     CVE-2026-72240, CVE-2026-72241, CVE-2026-72245, CVE-2026-72247, CVE-2026-72250, CVE-2026-72251,     CVE-2026-72256, CVE-2026-72264, CVE-2026-72265, CVE-2026-72267, CVE-2026-72268, CVE-2026-72269,     CVE-2026-72270, CVE-2026-72271, CVE-2026-72272, CVE-2026-72274, CVE-2026-72275, CVE-2026-72276,     CVE-2026-72282, CVE-2026-72289, CVE-2026-72296, CVE-2026-72297, CVE-2026-72298, CVE-2026-72306,     CVE-2026-72307, CVE-2026-72310, CVE-2026-72314, CVE-2026-72316, CVE-2026-72319, CVE-2026-72322,     CVE-2026-72326, CVE-2026-72339, CVE-2026-72347, CVE-2026-72348, CVE-2026-72349, CVE-2026-72350,     CVE-2026-72351, CVE-2026-72371, CVE-2026-72374, CVE-2026-72378, CVE-2026-72389, CVE-2026-72392,     CVE-2026-72396, CVE-2026-72400, CVE-2026-72406, CVE-2026-72409, CVE-2026-72414, CVE-2026-72418,     CVE-2026-72421, CVE-2026-72422, CVE-2026-72428, CVE-2026-72433, CVE-2026-72435, CVE-2026-72441,     CVE-2026-72447, CVE-2026-72448, CVE-2026-72450, CVE-2026-72459, CVE-2026-72460, CVE-2026-72466,     CVE-2026-72476, CVE-2026-72479, CVE-2026-72481, CVE-2026-72483, CVE-2026-72484, CVE-2026-72489,     CVE-2026-72491, CVE-2026-72492, CVE-2026-72502, CVE-2026-74255, CVE-2026-74256, CVE-2026-74262,     CVE-2026-74265, CVE-2026-74267, CVE-2026-74276, CVE-2026-74279, CVE-2026-74280, CVE-2026-74281,     CVE-2026-74282, CVE-2026-74283, CVE-2026-74284, CVE-2026-74287, CVE-2026-74288, CVE-2026-74292,     CVE-2026-74293, CVE-2026-74295, CVE-2026-74297, CVE-2026-74305, CVE-2026-74312, CVE-2026-74313,     CVE-2026-74320, CVE-2026-74321, CVE-2026-74327, CVE-2026-74329, CVE-2026-74330, CVE-2026-74331,     CVE-2026-74339, CVE-2026-74340, CVE-2026-74346, CVE-2026-74348, CVE-2026-74349, CVE-2026-74351,     CVE-2026-74359, CVE-2026-74363, CVE-2026-74376, CVE-2026-74379, CVE-2026-74382, CVE-2026-74384,     CVE-2026-74390, CVE-2026-74394, CVE-2026-74395, CVE-2026-74398, CVE-2026-74399, CVE-2026-74402,     CVE-2026-74408, CVE-2026-74410, CVE-2026-74416, CVE-2026-74424, CVE-2026-74426, CVE-2026-74427,     CVE-2026-74438, CVE-2026-74443, CVE-2026-74444, CVE-2026-74453, CVE-2026-74455, CVE-2026-74456,     CVE-2026-74457, CVE-2026-74458, CVE-2026-74459, CVE-2026-74460, CVE-2026-74461, CVE-2026-74463,     CVE-2026-74464, CVE-2026-74465, CVE-2026-74467, CVE-2026-74468, CVE-2026-74469, CVE-2026-74471,     CVE-2026-74473, CVE-2026-74475, CVE-2026-74478, CVE-2026-74480, CVE-2026-74481, CVE-2026-74482,     CVE-2026-74485, CVE-2026-74488, CVE-2026-74490, CVE-2026-74492, CVE-2026-74493, CVE-2026-74495,     CVE-2026-74497, CVE-2026-74498, CVE-2026-74499, CVE-2026-74505, CVE-2026-74507, CVE-2026-74508,     CVE-2026-74512, CVE-2026-74518, CVE-2026-74519, CVE-2026-74523, CVE-2026-74525, CVE-2026-74540,     CVE-2026-74546, CVE-2026-74547, CVE-2026-74548, CVE-2026-74549, CVE-2026-74556, CVE-2026-74557,     CVE-2026-74563, CVE-2026-74564, CVE-2026-74566, CVE-2026-74567, CVE-2026-74569, CVE-2026-74577,     CVE-2026-74578, CVE-2026-74579)

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1787305050 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1787305050 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1788170774 advisory.

  - A race condition in Linux kernel SCTP sockets (net/sctp/socket.c) before 5.12-rc8 can lead to kernel     privilege escalation from the context of a network service or an unprivileged process. If     sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock then an element is removed from the     auto_asconf_splist list without any proper locking. This can be exploited by an attacker with network     service privileges to escalate to root or from the context of an unprivileged user directly if a     BPF_CGROUP_INET_SOCK_CREATE is attached which denies creation of some SCTP socket. (CVE-2021-23133)

  - In the Linux kernel, the following vulnerability has been resolved: drm: Fix use-after-free read in     drm_getunique() There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving     file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report     of the use-after-free error found by Syzbot:
    https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master     pointer was used after being freed. This is because another process had acquired the device's master mutex     in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of     fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's     master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot     reproducer test. (CVE-2021-47280)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during     drive powercycle test While looping over shost's sdev list it is possible that one of the drives is     getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a     kernel panic can occur while the driver is trying to access the sas_address field of sas_target object     without also checking the sas_target object for NULL. (CVE-2021-47565)

  - In the Linux kernel, the following vulnerability has been resolved: dm btree remove: fix use after free in     rebalance_children() Move dm_tm_unlock() after dm_tm_dec(). (CVE-2021-47600)

  - In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-     of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing     validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value     remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the     easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
    (CVE-2022-49478)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The CentOS Linux 6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS6:CLSA-2026:1791949745 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report     buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it     during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted     report. (CVE-2024-50302)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-     bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that     exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-     of-bounds accesses later, e.g. in usb_destroy_configuration. (CVE-2024-53197)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace     cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid,     creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can     also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied     without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to     request the key. (CVE-2026-46243)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access     bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same     socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial     Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework     bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking     the child socket. (CVE-2026-52918)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP     rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind     skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is     addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking     skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would     reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender     hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to     skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only     safely reads the ARP header; it does not make the later sender hardware address range writable. If that     range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits()     maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable     before reading the ARP header and before calling skb_store_bits(). (CVE-2026-53266)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
364675	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1791780738)	Nessus	CentOS Local Security Checks	2026/10/12	2026/10/12	high
365381	Ubuntu 22.04 LTS : Linux kernel (GCP) vulnerabilities (USN-8877-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	high
365459	Ubuntu 22.04 LTS : Linux kernel (Azure CVM) vulnerabilities (USN-8876-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	high
365522	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-8917-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
352220	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	high
366749	SUSE SLES12: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:4687-1)	Nessus	SuSE Local Security Checks	2026/10/17	2026/10/17	high
352240	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Rocky Linux Local Security Checks	2026/9/30	2026/9/30	high
359803	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1788170774)	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
365463	Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	medium
367921	CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1791949745)	Nessus	CentOS Local Security Checks	2026/10/20	2026/10/22	high
347900	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:4254-1)	Nessus	SuSE Local Security Checks	2026/9/18	2026/9/29	high

检测

插件搜索

high

high

high

medium

high

high

high

high

medium

high

high