The remote Oracle Linux 10 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2025-20530 advisory.

    - sunrpc: handle SVC_GARBAGE during svc auth processing as auth error (Jeff Layton)  [Orabug: 38137447]     {CVE-2025-38089}
    - Add Zen34 clients (Borislav Petkov (AMD))  [Orabug: 38172252]  {CVE-2024-36350} {CVE-2024-36357}
    - x86/process: Move the buffer clearing before MONITOR (Kim Phillips)  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}
    - Add normal counters (Borislav Petkov (AMD))  [Orabug: 38172252]  {CVE-2024-36350} {CVE-2024-36357}
    - KVM: SVM: Advertize TSA CPUID bits to guests (Borislav Petkov (AMD))  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}
    - x86/bugs: Add a Transient Scheduler Attacks mitigation (Borislav Petkov (AMD))  [Orabug: 38172252]     {CVE-2024-36350} {CVE-2024-36357}

Tenable has extracted the preceding description block directly from the Oracle Linux 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 remote Ubuntu 20.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-7820-1 advisory.

    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:

    - Ext4 file system;

    - Network file system (NFS) server daemon;

    - Packet sockets;

    - Network traffic control;

    - VMware vSockets driver; (CVE-2025-37785, CVE-2025-38618, CVE-2025-38617, CVE-2024-57996, CVE-2025-37752,     CVE-2025-38477, CVE-2025-21796, CVE-2025-38350)

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 remote SUSE Linux SLES12 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:4123-1 advisory.

    This update for the SUSE Linux Enterprise kernel 4.12.14-122.231 fixes various security issues

    The following security issues were fixed:

    - CVE-2022-48956: ipv6: avoid use-after-free in ip6_fragment() (bsc#1232637).
    - CVE-2022-49014: net: tun: Fix use-after-free in tun_detach() (bsc#1232818).
    - CVE-2022-49053: scsi: target: tcmu: Fix possible page UAF (bsc#1237930).
    - CVE-2022-49080: mm/mempolicy: fix mpol_new leak in shared_policy_replace (bsc#1238324).
    - CVE-2022-49179: block, bfq: don't move oom_bfqq (bsc#1241331).
    - CVE-2022-49465: blk-throttle: set BIO_THROTTLED when bio has been throttled (bsc#1238920).
    - CVE-2022-49545: ALSA: usb-audio: cancel pending work at closing a MIDI substream (bsc#1238730).
    - CVE-2022-49563: crypto: qat - add param check for RSA (bsc#1238788).
    - CVE-2022-49564: crypto: qat - add param check for DH (bsc#1238790).
    - CVE-2022-50252: igb: Do not free q_vector unless new one was allocated (bsc#1249847).
    - CVE-2022-50386: Bluetooth: L2CAP: Fix user-after-free (bsc#1250302).
    - CVE-2024-45016: netem: fix return value if duplicate enqueue fails (bsc#1230998).
    - CVE-2024-46818: drm/amd/display: check gpio_id before used as array index (bsc#1231204).
    - CVE-2024-47674: mm: avoid leaving partial pfn mappings around in error case (bsc#1231676).
    - CVE-2024-47684: tcp: check skb is non-NULL in tcp_rto_delta_us() (bsc#1231993).
    - CVE-2024-47706: block, bfq: fix possible UAF for bfqq->bic with merge chain (bsc#1231943).
    - CVE-2024-49860: ACPI: sysfs: validate return type of _STR method (bsc#1231862).
    - CVE-2024-50115: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory (bsc#1233019).
    - CVE-2024-50125: Bluetooth: SCO: Fix UAF on sco_sock_timeout (bsc#1232929).
    - CVE-2024-50154: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() (bsc#1233072).
    - CVE-2024-50264: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans     (bsc#1233712).
    - CVE-2024-50279: dm cache: fix out-of-bounds access to the dirty bitset when resizing (bsc#1233708).
    - CVE-2024-50301: security/keys: fix slab-out-of-bounds in key_task_permission (bsc#1233680).
    - CVE-2024-50302: HID: core: zero-initialize the report buffer (bsc#1233679).
    - CVE-2024-53104: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format     (bsc#1236783).
    - CVE-2024-53146: NFSD: prevent a potential integer overflow (bsc#1234854).
    - CVE-2024-53156: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() (bsc#1234847).
    - CVE-2024-53168: sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket (bsc#1243650).
    - CVE-2024-53173: NFSv4.0: Fix a use-after-free problem in the asynchronous open() (bsc#1234892).
    - CVE-2024-53214: vfio/pci: Properly hide first-in-list PCIe extended capability (bsc#1235005).
    - CVE-2024-56600: net: inet6: do not leave a dangling sk pointer in inet6_create() (bsc#1235218).
    - CVE-2024-56601: net: inet: do not leave a dangling sk pointer in inet_create() (bsc#1235231).
    - CVE-2024-56605: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()     (bsc#1235062).
    - CVE-2024-56650: netfilter: x_tables: fix LED ID check in led_tg_check() (bsc#1235431).
    - CVE-2024-56664: bpf, sockmap: fix race between element replace and close() (bsc#1235250).
    - CVE-2024-57893: ALSA: seq: oss: fix races at processing SysEx messages (bsc#1235921).
    - CVE-2024-57996: net_sched: sch_sfq: don't allow 1 packet limit (bsc#1239077).
    - CVE-2024-8805: BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability     (bsc#1240840).
    - CVE-2025-21702: pfifo_tail_enqueue: Drop new packet when sch->limit == 0 (bsc#1245797).
    - CVE-2025-21772: partitions: mac: fix handling of bogus partition table (bsc#1238912).
    - CVE-2025-21791: vrf: use RCU protection in l3mdev_l3_out() (bsc#1240744).
    - CVE-2025-21971: net_sched: Prevent creation of classes with TC_H_ROOT (bsc#1245794).
    - CVE-2025-37752: net_sched: sch_sfq: move the limit validation (bsc#1245776).
    - CVE-2025-37797: net_sched: hfsc: Fix a UAF vulnerability in class handling (bsc#1245793).
    - CVE-2025-38000: sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() (bsc#1245775).
    - CVE-2025-38079: crypto: algif_hash - fix double free in hash_accept (bsc#1245218).
    - CVE-2025-38083: net_sched: prio: fix a race in prio_tune() (bsc#1245350).
    - CVE-2025-38177: kernel: sch_hfsc: make hfsc_qlen_notify() idempotent (bsc#1246356).
    - CVE-2025-38181: calipso: fix null-ptr-deref in calipso_req_{set,del}attr() (bsc#1246001).
    - CVE-2025-38212: ipc: fix to protect IPCS lookups using RCU (bsc#1246030).
    - CVE-2025-38477: net/sched: sch_qfq: Fix race condition on qfq_aggregate (bsc#1247315).
    - CVE-2025-38494: HID: core: do not bypass hid_hw_raw_request (bsc#1247350).
    - CVE-2025-38495: HID: core: ensure the allocated report buffer can contain the reserved report ID     (bsc#1247351).
    - CVE-2025-38498: do_change_type(): refuse to operate on unmounted/not ours mounts (bsc#1247499).
    - CVE-2025-38499: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns     (bsc#1248673).
    - CVE-2025-38617: net/packet: fix a race in packet_set_ring() and packet_notifier() (bsc#1249208).
    - CVE-2025-38618: vsock: Do not allow binding to VMADDR_PORT_ANY (bsc#1249207).
    - CVE-2025-38644: wifi: mac80211: reject TDLS operations when station is not associated (bsc#1248749).

    The following non security issues were fixed:

    - Add the git commit and branch to the package description (bsc#920633)
    - Fix description in rpm spec file Spec file description mentions initial kGraft patch which is only true     for real initial patch. Make it more neutral. (bsc#930408)
    - Mark the module as supported (bsc#904970)
    - Provide common kallsyms wrapper API With bsc#1103203, the need for disambiguating between a multiply     defined symbol arose. This is something the kallsyms_lookup_name() based code snippet we used to     copy&paste to every individual CVE fix can't handle. Implement a proper wrapper API for doing the kallsyms     lookups.
    - Require exact kernel version in the patch (bsc#920615)
    - Revert 'Require exact kernel version in the patch' This needs to be done differently, so that modprobe
    --force works as expected. (bsc#920615) This reverts commit c62c11aecd4e3f8822e1b835fea403acc3148c5a.
    - Set immediate flag for the initial patch Setting immediate to true will simplify installation of the     initial patch and possibly also of the further updates. (bsc#907150)
    - The stubs' signatures have changed: each argument used to get mapped to either long or long long, but on     x86_64, the stubs are now receiving a single struct pt_regs only -- it's their responsibility to extract     the arguments as appropriate. In order to not require each and every live patch touching syscalls to     include an insane amount of ifdeffery, provide a set of #defines hiding it: 1.) KLP_SYSCALL_SYM(name)     expands to the syscall stub name for 64 bits as defined by _SYSCALL_DEFINEx(x, _name, ...). 2.) If the     architeture requires 32bit specific stubs for syscalls sharing a common implementation between 32 and     64bits, the KLP_ARCH_HAS_SYSCALL_COMPAT_STUBS macro is defined. 3.) If KLP_ARCH_HAS_SYSCALL_COMPAT_STUBS     is defined, then KLP_SYSCALL_COMPAT_STUB_SYM(name) expands to the syscall stub name for 32 bits as defined     by _SYSCALL_DEFINEx(x, _name, ...). 4.) For syscalls not sharing a common implementation between 32 and 64     bits, i.e. those defined by COMPAT_SYSCALL_DEFINEx(), the macro KLP_COMPAT_SYSCALL_SYM(name) expands to     the stub name defined as defined by COMPAT_SYSCALL_DEFINEx(x, _name, ...). 5.) Finally, for hiding     differences between the signatures, provide the macro KLP_SYSCALL_DECLx(x, sym, ...) which expands to a     declaration of sym, with the x arguments either mapped to long resp. long long each, or collapsed to a     single struct pt_regs argument as appropriate for the architecture. Note that these macros are defined as     appropriate on kernels before and after 4.17, so that live patch code can be shared. (bsc#1149841)
    - bsc#1249208: fix livepatching target module name (bsc#1252946)
    - uname_patch: convert to the syscall stub wrapper macros from klp_syscalls.h In order to make the live     patch to the newuname() syscall work on kernels >= 4.17 again, convert it to the KLP_SYSCALL_*() wrapper     macros provided by klp_syscalls.h. (bsc#1149841)

Tenable has extracted the preceding description block directly from the SUSE 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.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1783791447 advisory.

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

  - An out-of-bounds read flaw was found in the Linux kernel's TeleTYpe subsystem. The issue occurs in how a     user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage     of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read     unauthorized random data from memory. (CVE-2022-1462)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

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

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

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:1780562693 advisory.

  - An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to     obtain sensitive information from heap memory via crafted frame lengths from a device. (CVE-2022-26966)

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

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

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

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller     to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit     ac0a230f719b (eth: sungem: remove .ndo_poll_controller to avoid deadlocks). The root cause of the issue     is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of     sungem driver, however, disable_irq() might sleep. After analyzing the implementation of     fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX     completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so     fec_poll_controller() can be safely removed. (CVE-2024-38553)

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

ID	Name	Product	Family	Published	Updated	Severity
252244	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2025-20530)	Nessus	Oracle Linux Local Security Checks	8/19/2025	2/9/2026	medium
270456	Ubuntu 20.04 LTS : Linux kernel (Oracle) vulnerabilities (USN-7820-1)	Nessus	Ubuntu Local Security Checks	10/15/2025	10/15/2025	high
275755	SUSE SLES12 Security Update : kernel (Live Patch 61 for SUSE Linux Enterprise 12 SP5) (SUSE-SU-2025:4123-1)	Nessus	SuSE Local Security Checks	11/19/2025	11/19/2025	high
352871	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1783791447)	Nessus	Alma Linux Local Security Checks	9/30/2026	10/22/2026	low
361300	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1780562693)	Nessus	Alma Linux Local Security Checks	10/1/2026	10/21/2026	high

Detections

Analytics

Plugins Search

medium

high

high

low

high