In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix use-after-free on input2 registration failure alps_input_configured() stores data->input2 before calling input_register_device(). If registration fails, input_free_device() frees the input device but data->input2 still points to the freed memory. alps_input_configured() calls hid_hw_open() before allocating input2, so URBs are already active and raw_event can fire during the failure window. A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event() to dereference the freed data->input2 -> use-after-free. Fix by only storing input2 into drvdata after successful registration and adding a NULL guard in the raw_event path.

tuxcare CENTOS-STREAM8:CLSA-2026:1794319147: kernel: Fix of 162 CVEs (Critical)

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1794319150 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for     malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion     before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement     Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
    Commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting Receives) moved the     Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into     rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-     version and short-reply exits never reach that refill: they recycle the rep and return without calling     rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a     sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized     RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue     empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both     malformed-reply exits through the shared repost tail after recycling the rep, refilling against     buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so     RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would     let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the     congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun     the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK     terminates the connection. Refilling against rb_credits also restores the target that applied to malformed     replies before commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting     Receives) when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one     from connection establishment onward, so the repost path always keeps Receives posted. (CVE-2026-72464)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: check RCV_SHUTDOWN after the     sendmsg connect wait sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue     ABORT can then be processed from the socket backlog and unlink the association. If a concurrent     shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead.
    Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue     with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before     using the association again. The check only accesses the socket, so it needs no additional association     reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may     already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the     connect() caller. (CVE-2026-98846)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in     enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user     context. The spinlock protects the backlog queue in this path, but it does not serialize against the     socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3     Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123     print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597
    __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0     net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60     net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188     tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689
    __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400     sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884     do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431
    __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41     do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e     arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89     d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00     00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX:
    0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f     RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09:
    0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021     R14: 0000000000000000 R15: 00007fff89799c40 </TASK> The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue()     also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued     or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held     spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the     socket is owned by user context. (CVE-2026-72299)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length     in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized     buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0,     without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with     dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same     unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a     client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS     mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
    -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name(). (CVE-2026-89652)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in     NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying     an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes     cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.
    Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which     does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity     (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via     inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's     ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field     and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS     with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the     proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for     SETATTR and describes it as the error for a value the server 'can not store ... in its own     representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in     nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object     before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-     idempotent request into a namespace change that reports failure. The check is therefore done up front, for     the create operations before the object is created. tv_nsec is a long, so the comparison casts it to     unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate     on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire     nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME     requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard     simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison,     which is the protocol-correct outcome rather than rejecting the request. (CVE-2026-89666)

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

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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

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

    - NFSD: Define actions for the new time_deleg FATTR4 attributes (Chuck Lever)  [Orabug: 39004166]     {CVE-2025-40326}
    - ipv4: free inet_opt and ireq_opt after an RCU grace period (Eric Dumazet)  [Orabug: 40165787]     {CVE-2026-98432}
    - ipv4: validate checksum_start before completing checksum (Michael S. Tsirkin)  [Orabug: 40165809]     {CVE-2026-99999}
    - mm/pagewalk: fix stale walk->action escaping walk_pmd_range() (Hyunwoo Kim)  [Orabug: 40022020]     {CVE-2026-89754}

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 Oracle Linux 8 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-500574 advisory.

    - ipv4: validate checksum_start before completing checksum (Michael S. Tsirkin)  [Orabug: 40165811]     {CVE-2026-99999}
    - ipv4: free inet_opt and ireq_opt after an RCU grace period (Eric Dumazet)  [Orabug: 40165788]     {CVE-2026-98432}
    - exec: Cleanup POSIX timers right after de_thread() (Hyunwoo Kim)  [Orabug: 40120750]  {CVE-2026-98260}

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.

An update of the linux package has been released.

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

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: avoid uninit memory read     in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for     ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but     ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that     pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and     ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not     known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at if     (pkt_len > 2 * MAX_RX_BUF_SIZE) { line in ath9k_hif_usb_rx_stream(). We have two choices. One is to     workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to     let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not     sure threshold condition is correct, for I can't find details on possible packet length used by this     protocol. (CVE-2022-50709)

  - In the Linux kernel, the following vulnerability has been resolved: configfs: fix possible memory leak in     configfs_create_dir() kmemleak reported memory leaks in configfs_create_dir(): unreferenced object     0xffff888009f6af00 (size 192): comm modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace:
    kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment     (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857)     basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296)     do_init_module (kernel/module/main.c:2455) ... unreferenced object 0xffff888003ba7180 (size 96): comm     modprobe, pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250     mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723     fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir     (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)     configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14)     stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... This is     because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing     as: configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set     s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem()     configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ...
    *dentry_unlink_inode()* configfs_d_iput() # s_count = 0, release However, if we failed in     configfs_create(): configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count =     2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1     return PTR_ERR(inode); There is no inode in the error path, so the configfs_d_iput() is lost and makes sd     and fragment memory leaked. To fix this, when we failed in configfs_create(), manually call     configfs_put(sd) to keep the refcount correct. (CVE-2022-50751)

  - In the Linux kernel, the following vulnerability has been resolved: pstore: Avoid kcore oops by vmap()ing     with VM_IOREMAP An oops can be induced by running 'cat /proc/kcore > /dev/null' on devices using pstore     with the ram backend because kmap_atomic() assumes lowmem pages are accessible with __va(). Unable to     handle kernel paging request at virtual address ffffff807ff2b000 Mem abort info: ESR = 0x96000006 EC =     0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation     fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs,     pgdp=0000000081d87000 [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003,     pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: dm_integrity CPU:
    7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1     baa443fb8e8477896a370b31a821eb2009f9bfba Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a0400009     (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x110/0x260 lr : vread+0x194/0x294 sp :
    ffffffc013ee39d0 x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000 x26: 0000000000001000     x25: ffffffc0085a2000 x24: ffffff802d4b3000 x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21:
    ffffffc0085a2000 x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000 x17: 0000000000000000     x16: 0000000000000000 x15: ffffffd3073f2e60 x14: ffffffffad588000 x13: 0000000000000000 x12:
    0000000000000001 x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b x8 : 0000000000000001     x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 :
    ffffffc013ee3a78 x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000 Call trace:
    __memcpy+0x110/0x260 read_kcore+0x584/0x778 proc_reg_read+0xb4/0xe4 During early boot, memblock reserves     the pages for the ramoops reserved memory node in DT that would otherwise be part of the direct lowmem     mapping. Pstore's ram backend reuses those reserved pages to change the memory type (writeback or non-     cached) by passing the pages to vmap() (see pfn_to_page() usage in persistent_ram_vmap() for more details)     with specific flags. When read_kcore() starts iterating over the vmalloc region, it runs over the virtual     address that vmap() returned for ramoops. In aligned_vread() the virtual address is passed to     vmalloc_to_page() which returns the page struct for the reserved lowmem area. That lowmem page is passed     to kmap_atomic(), which effectively calls page_to_virt() that assumes a lowmem page struct must be     directly accessible with __va() and friends. These pages are mapped via vmap() though, and the lowmem     mapping was never made, so accessing them via the lowmem virtual address oopses like above. Let's side-     step this problem by passing VM_IOREMAP to vmap(). This will tell vread() to not include the ramoops     region in the kcore. Instead the area will look like a bunch of zeros. The alternative is to teach kmap()     about vmalloc areas that intersect with lowmem. Presumably such a change isn't a one-liner, and there     isn't much interest in inspecting the ramoops region in kcore files anyway, so the most expedient route is     taken for now. (CVE-2022-50849)

  - In the Linux kernel, the following vulnerability has been resolved: hwrng: amd - Fix PCI device refcount     leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it     will increase the reference count for the returned pci_dev and also decrease the reference count for the     input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to     call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the normal and error     path. (CVE-2022-50868)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from     srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs     one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call     scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions     would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the     srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is     returned. (CVE-2023-52515)

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

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4850 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4850-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     October 22, 2026                              https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.113-1~deb12u1     CVE ID         : CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315                      CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937                      CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437                      CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467                      CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527                      CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795                      CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832                      CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859                      CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956                      CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002                      CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029                      CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196                      CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243                      CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528                      CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532                      CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537                      CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566                      CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594                      CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615                      CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901                      CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933                      CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939                      CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161                      CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170                      CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174                      CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182                      CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187                      CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191                      CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195                      CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199                      CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203                      CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207                      CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211                      CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215                      CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221                      CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230                      CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234                      CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238                      CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246                      CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251                      CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255                      CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262                      CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266                      CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271                      CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282                      CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291                      CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298                      CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302                      CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308                      CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314                      CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322                      CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327                      CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334                      CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339                      CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344                      CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348                      CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354                      CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360                      CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366                      CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370                      CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377                      CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381                      CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386                      CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409                      CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413                      CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421                      CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426                      CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432                      CVE-2026-98433 CVE-2026-98435 CVE-2026-98440 CVE-2026-98441                      CVE-2026-98442 CVE-2026-98443 CVE-2026-98445 CVE-2026-98448                      CVE-2026-98450 CVE-2026-98451 CVE-2026-98452 CVE-2026-98453                      CVE-2026-98454 CVE-2026-98455 CVE-2026-98456 CVE-2026-98457                      CVE-2026-98458 CVE-2026-98459 CVE-2026-98460 CVE-2026-98461                      CVE-2026-98462 CVE-2026-98464 CVE-2026-98465 CVE-2026-98468                      CVE-2026-98473 CVE-2026-98475 CVE-2026-98476 CVE-2026-98477                      CVE-2026-98479 CVE-2026-98481 CVE-2026-98482 CVE-2026-98483                      CVE-2026-98484 CVE-2026-98485 CVE-2026-98486 CVE-2026-98487                      CVE-2026-98488 CVE-2026-98489 CVE-2026-98490 CVE-2026-98491                      CVE-2026-98493 CVE-2026-98494 CVE-2026-98495 CVE-2026-98498                      CVE-2026-98499 CVE-2026-98501 CVE-2026-98502 CVE-2026-98503                      CVE-2026-98504 CVE-2026-98505 CVE-2026-98506 CVE-2026-98507                      CVE-2026-98508 CVE-2026-98509 CVE-2026-98510 CVE-2026-98511                      CVE-2026-98512 CVE-2026-98513 CVE-2026-98514 CVE-2026-98515                      CVE-2026-98516 CVE-2026-98517 CVE-2026-98519 CVE-2026-98521                      CVE-2026-98522 CVE-2026-98523 CVE-2026-98524 CVE-2026-98525                      CVE-2026-98526 CVE-2026-98527 CVE-2026-98528 CVE-2026-98529                      CVE-2026-98531 CVE-2026-98532 CVE-2026-98533 CVE-2026-98534                      CVE-2026-98535 CVE-2026-98536 CVE-2026-98537 CVE-2026-98538                      CVE-2026-98539 CVE-2026-98541 CVE-2026-98544 CVE-2026-98545                      CVE-2026-98546 CVE-2026-98547 CVE-2026-98548 CVE-2026-98549                      CVE-2026-98550 CVE-2026-98553 CVE-2026-98554 CVE-2026-98555                      CVE-2026-98559 CVE-2026-98561 CVE-2026-98565 CVE-2026-98566                      CVE-2026-98567 CVE-2026-98568 CVE-2026-98569 CVE-2026-98572                      CVE-2026-98573 CVE-2026-98575 CVE-2026-98576 CVE-2026-98577                      CVE-2026-98578 CVE-2026-98579 CVE-2026-98580 CVE-2026-98581                      CVE-2026-98582 CVE-2026-98583 CVE-2026-98586 CVE-2026-98588                      CVE-2026-98590 CVE-2026-98591 CVE-2026-98593 CVE-2026-98594                      CVE-2026-98596 CVE-2026-98597 CVE-2026-98600 CVE-2026-98601                      CVE-2026-98602 CVE-2026-98605 CVE-2026-98606 CVE-2026-98607                      CVE-2026-98608 CVE-2026-98609 CVE-2026-98610 CVE-2026-98611                      CVE-2026-98612 CVE-2026-98613 CVE-2026-98614 CVE-2026-98615                      CVE-2026-98618 CVE-2026-98620 CVE-2026-98621 CVE-2026-98622                      CVE-2026-98623 CVE-2026-98624 CVE-2026-98625 CVE-2026-98626                      CVE-2026-98629 CVE-2026-98631 CVE-2026-98632 CVE-2026-98634                      CVE-2026-98636 CVE-2026-98640 CVE-2026-98641 CVE-2026-98642                      CVE-2026-98643 CVE-2026-98644 CVE-2026-98646 CVE-2026-98647                      CVE-2026-98655 CVE-2026-98656 CVE-2026-98657 CVE-2026-98658                      CVE-2026-98660 CVE-2026-98661 CVE-2026-98662 CVE-2026-98663                      CVE-2026-98664 CVE-2026-98665 CVE-2026-98666 CVE-2026-98668                      CVE-2026-98669 CVE-2026-98670 CVE-2026-98671 CVE-2026-98672                      CVE-2026-98673 CVE-2026-98677 CVE-2026-98679 CVE-2026-98680                      CVE-2026-98681 CVE-2026-98686 CVE-2026-98687 CVE-2026-98694                      CVE-2026-98695 CVE-2026-98696 CVE-2026-98697 CVE-2026-98698                      CVE-2026-98699 CVE-2026-98700 CVE-2026-98701 CVE-2026-98702                      CVE-2026-98703 CVE-2026-98704 CVE-2026-98705 CVE-2026-98706                      CVE-2026-98707 CVE-2026-98708 CVE-2026-98709 CVE-2026-98710                      CVE-2026-98711 CVE-2026-98713 CVE-2026-98716 CVE-2026-98717                      CVE-2026-98720 CVE-2026-98721 CVE-2026-98722 CVE-2026-98725                      CVE-2026-98726 CVE-2026-98727 CVE-2026-98728 CVE-2026-98730                      CVE-2026-98731 CVE-2026-98732 CVE-2026-98733 CVE-2026-98734                      CVE-2026-98735 CVE-2026-98736 CVE-2026-98737 CVE-2026-98738                      CVE-2026-98739 CVE-2026-98741 CVE-2026-98742 CVE-2026-98743                      CVE-2026-98744 CVE-2026-98745 CVE-2026-98746 CVE-2026-98748                      CVE-2026-98749 CVE-2026-98750 CVE-2026-98751 CVE-2026-98752                      CVE-2026-98753 CVE-2026-98754 CVE-2026-98755 CVE-2026-98756                      CVE-2026-98757 CVE-2026-98758 CVE-2026-98760 CVE-2026-98761                      CVE-2026-98762 CVE-2026-98763 CVE-2026-98764 CVE-2026-98765                      CVE-2026-98766 CVE-2026-98767 CVE-2026-98768 CVE-2026-98769                      CVE-2026-98770 CVE-2026-98771 CVE-2026-98772 CVE-2026-98773                      CVE-2026-98775 CVE-2026-98777 CVE-2026-98778 CVE-2026-98779                      CVE-2026-98780 CVE-2026-98781 CVE-2026-98782 CVE-2026-98783                      CVE-2026-98784 CVE-2026-98785 CVE-2026-98790 CVE-2026-98791                      CVE-2026-98792 CVE-2026-98793 CVE-2026-98794 CVE-2026-98796                      CVE-2026-98797 CVE-2026-98798 CVE-2026-98801 CVE-2026-98805                      CVE-2026-98807 CVE-2026-98808 CVE-2026-98809 CVE-2026-98811                      CVE-2026-98812 CVE-2026-98819 CVE-2026-98822 CVE-2026-98823                      CVE-2026-98825 CVE-2026-98826 CVE-2026-98827 CVE-2026-98828                      CVE-2026-98830 CVE-2026-98831 CVE-2026-98833 CVE-2026-98835                      CVE-2026-98836 CVE-2026-98837 CVE-2026-98838 CVE-2026-98840                      CVE-2026-98841 CVE-2026-98844 CVE-2026-98845 CVE-2026-98846                      CVE-2026-98847 CVE-2026-98848 CVE-2026-98849 CVE-2026-98850                      CVE-2026-98851 CVE-2026-98852 CVE-2026-98854 CVE-2026-98855                      CVE-2026-98856 CVE-2026-98857 CVE-2026-98858 CVE-2026-98859                      CVE-2026-98860 CVE-2026-98862 CVE-2026-99999     Debian Bug     : 1149499 1149564 1150891

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.113-1~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.112 and 6.12.113.

    We recommend that you upgrade your linux-6.12 packages.

    For the detailed security status of linux-6.12 please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux-6.12

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian 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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - HID: alps: fix use-after-free on input2 registration failure alps_input_configured() stores data->input2     before calling input_register_device(). If registration fails, input_free_device() frees the input device     but data->input2 still points to the freed memory. alps_input_configured() calls hid_hw_open() before     allocating input2, so URBs are already active and raw_event can fire during the failure window. A     U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event() to dereference the freed data->input2
    -> use-after-free. Fix by only storing input2 into drvdata after successful registration and adding a NULL     guard in the raw_event path. (CVE-2026-98501)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
378425	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1794319150)	Nessus	CentOS Local Security Checks	Local	high
377778	Ubuntu 20.04 LTS / 22.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-8963-1)	Nessus	Ubuntu Local Security Checks	Local	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
376433	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Alma Linux Local Security Checks	Local	high
376432	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Rocky Linux Local Security Checks	Local	high
376285	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:5091-1)	Nessus	SuSE Local Security Checks	Local	critical
375804	Ubuntu 20.04 LTS / 22.04 LTS : Linux kernel vulnerabilities (USN-8961-1)	Nessus	Ubuntu Local Security Checks	Local	high
375469	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500572)	Nessus	Oracle Linux Local Security Checks	Local	medium
375468	Oracle Linux 8 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500574)	Nessus	Oracle Linux Local Security Checks	Local	high
374972	Photon OS 5.0: Linux PHSA-2026-5.0-92-1026	Nessus	PhotonOS Local Security Checks	Local	medium
374124	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792976962)	Nessus	CentOS Local Security Checks	Local	high
370518	Debian dla-4850 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
367303	Linux Distros Unpatched Vulnerability : CVE-2026-98501	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-98501

high

Tenable Plugins

Coming Soon

high

high

high

high

high

critical

high

medium

high

medium

high

high

high