The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - tracing: Save the event file instead of the compatible histogram create_field_var_hist() creates a     histogram on the matched event to supply a field variable, and records it on the target so it can be torn     down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram     information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that     was already there, whose keys the new one copies. The saved pointer has a single user,     unregister_field_var_hists(), which runs when the target is removed: file =     hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it     can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it     while the target still points at it: BUG: KASAN: slab-use-after-free in     event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task     1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0     trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and     it does not go away when the user removes a trigger. (CVE-2026-99235)

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

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 remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4904 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4904-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     November 13, 2026                             https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.115-2~deb12u1     CVE ID         : CVE-2024-58074 CVE-2025-22109 CVE-2025-23132 CVE-2025-23135                      CVE-2025-37743 CVE-2025-37746 CVE-2025-37906 CVE-2025-38029                      CVE-2025-38041 CVE-2025-38042 CVE-2025-38064 CVE-2025-38132                      CVE-2025-38137 CVE-2025-38140 CVE-2025-38187 CVE-2025-38199                      CVE-2025-38207 CVE-2025-38261 CVE-2025-38284 CVE-2025-38359                      CVE-2025-38421 CVE-2025-38597 CVE-2025-38605 CVE-2025-38636                      CVE-2025-38656 CVE-2025-39677 CVE-2025-39775 CVE-2025-39789                      CVE-2025-39830 CVE-2025-39834 CVE-2025-39859 CVE-2025-39862                      CVE-2025-39910 CVE-2025-39933 CVE-2025-39958 CVE-2025-40065                      CVE-2025-40086 CVE-2025-40113 CVE-2025-40130 CVE-2025-40136                      CVE-2025-40338 CVE-2025-40355 CVE-2025-68174 CVE-2025-68193                      CVE-2025-68209 CVE-2025-68236 CVE-2025-68318 CVE-2025-68319                      CVE-2025-68353 CVE-2025-68359 CVE-2025-68360 CVE-2025-68368                      CVE-2025-68376 CVE-2025-68729 CVE-2025-68730 CVE-2025-68735                      CVE-2025-68745 CVE-2025-68755 CVE-2025-71074 CVE-2025-71141                      CVE-2025-71227 CVE-2025-71285 CVE-2025-71313 CVE-2026-23007                      CVE-2026-23017 CVE-2026-23143 CVE-2026-23208 CVE-2026-23217                      CVE-2026-23259 CVE-2026-23327 CVE-2026-23371 CVE-2026-23377                      CVE-2026-23385 CVE-2026-23472 CVE-2026-31493 CVE-2026-31526                      CVE-2026-31562 CVE-2026-31579 CVE-2026-31592 CVE-2026-31630                      CVE-2026-31771 CVE-2026-43009 CVE-2026-43022 CVE-2026-43034                      CVE-2026-43042 CVE-2026-43048 CVE-2026-43053 CVE-2026-43083                      CVE-2026-43101 CVE-2026-43118 CVE-2026-43127 CVE-2026-43172                      CVE-2026-43185 CVE-2026-43191 CVE-2026-43204 CVE-2026-43213                      CVE-2026-43234 CVE-2026-43263 CVE-2026-43272 CVE-2026-43294                      CVE-2026-43298 CVE-2026-43299 CVE-2026-43308 CVE-2026-43309                      CVE-2026-43310 CVE-2026-43311 CVE-2026-43325 CVE-2026-43337                      CVE-2026-43346 CVE-2026-43352 CVE-2026-43353 CVE-2026-43414                      CVE-2026-43443 CVE-2026-43463 CVE-2026-43464 CVE-2026-43465                      CVE-2026-43485 CVE-2026-45932 CVE-2026-45934 CVE-2026-45940                      CVE-2026-45956 CVE-2026-45961 CVE-2026-46014 CVE-2026-46032                      CVE-2026-46044 CVE-2026-46059 CVE-2026-46066 CVE-2026-46071                      CVE-2026-46130 CVE-2026-46148 CVE-2026-46171 CVE-2026-46175                      CVE-2026-46181 CVE-2026-46228 CVE-2026-46245 CVE-2026-46256                      CVE-2026-46272 CVE-2026-46302 CVE-2026-46324 CVE-2026-46325                      CVE-2026-46330 CVE-2026-52937 CVE-2026-52956 CVE-2026-52983                      CVE-2026-52991 CVE-2026-53000 CVE-2026-53009 CVE-2026-53017                      CVE-2026-53018 CVE-2026-53024 CVE-2026-53025 CVE-2026-53091                      CVE-2026-53103 CVE-2026-53104 CVE-2026-53108 CVE-2026-53109                      CVE-2026-53118 CVE-2026-53178 CVE-2026-53224 CVE-2026-53258                      CVE-2026-53277 CVE-2026-53281 CVE-2026-53284 CVE-2026-53285                      CVE-2026-53292 CVE-2026-53297 CVE-2026-53321 CVE-2026-53330                      CVE-2026-53368 CVE-2026-53377 CVE-2026-53401 CVE-2026-63811                      CVE-2026-63825 CVE-2026-63832 CVE-2026-63853 CVE-2026-63857                      CVE-2026-63859 CVE-2026-63879 CVE-2026-63979 CVE-2026-63998                      CVE-2026-63999 CVE-2026-64006 CVE-2026-64024 CVE-2026-64036                      CVE-2026-64038 CVE-2026-64060 CVE-2026-64068 CVE-2026-64076                      CVE-2026-64077 CVE-2026-64079 CVE-2026-64117 CVE-2026-64146                      CVE-2026-64154 CVE-2026-64159 CVE-2026-64190 CVE-2026-64213                      CVE-2026-64283 CVE-2026-64388 CVE-2026-64389 CVE-2026-64400                      CVE-2026-64513 CVE-2026-68081 CVE-2026-68105 CVE-2026-68211                      CVE-2026-68233 CVE-2026-68238 CVE-2026-68241 CVE-2026-68242                      CVE-2026-68258 CVE-2026-68291 CVE-2026-68295 CVE-2026-68312                      CVE-2026-68323 CVE-2026-68375 CVE-2026-68383 CVE-2026-68393                      CVE-2026-68399 CVE-2026-68400 CVE-2026-68401 CVE-2026-68404                      CVE-2026-68409 CVE-2026-68412 CVE-2026-68418 CVE-2026-68421                      CVE-2026-68426 CVE-2026-68435 CVE-2026-68436 CVE-2026-68441                      CVE-2026-68447 CVE-2026-68448 CVE-2026-68453 CVE-2026-68470                      CVE-2026-68471 CVE-2026-72009 CVE-2026-72031 CVE-2026-72073                      CVE-2026-72098 CVE-2026-72162 CVE-2026-72288 CVE-2026-72321                      CVE-2026-72329 CVE-2026-72337 CVE-2026-72341 CVE-2026-72366                      CVE-2026-72367 CVE-2026-72375 CVE-2026-72380 CVE-2026-72383                      CVE-2026-72388 CVE-2026-72397 CVE-2026-72398 CVE-2026-72404                      CVE-2026-72423 CVE-2026-72439 CVE-2026-72440 CVE-2026-72488                      CVE-2026-72493 CVE-2026-72494 CVE-2026-72495 CVE-2026-72497                      CVE-2026-72499 CVE-2026-72500 CVE-2026-72501 CVE-2026-74257                      CVE-2026-74261 CVE-2026-74264 CVE-2026-74269 CVE-2026-74272                      CVE-2026-74273 CVE-2026-74317 CVE-2026-74338 CVE-2026-74344                      CVE-2026-74350 CVE-2026-74368 CVE-2026-74373 CVE-2026-74374                      CVE-2026-74375 CVE-2026-74385 CVE-2026-74388 CVE-2026-74405                      CVE-2026-74407 CVE-2026-74449 CVE-2026-74466 CVE-2026-74506                      CVE-2026-74513 CVE-2026-74520 CVE-2026-74527 CVE-2026-74529                      CVE-2026-74530 CVE-2026-74533 CVE-2026-74537 CVE-2026-74538                      CVE-2026-74542 CVE-2026-74544 CVE-2026-74558 CVE-2026-74559                      CVE-2026-74571 CVE-2026-74600 CVE-2026-74605 CVE-2026-74611                      CVE-2026-74687 CVE-2026-74690 CVE-2026-74695 CVE-2026-74697                      CVE-2026-74711 CVE-2026-74713 CVE-2026-74715 CVE-2026-74723                      CVE-2026-74728 CVE-2026-74729 CVE-2026-74733 CVE-2026-74734                      CVE-2026-74747 CVE-2026-74752 CVE-2026-74754 CVE-2026-80581                      CVE-2026-80607 CVE-2026-80614 CVE-2026-80616 CVE-2026-80623                      CVE-2026-80628 CVE-2026-80631 CVE-2026-80634 CVE-2026-80643                      CVE-2026-80653 CVE-2026-80655 CVE-2026-80662 CVE-2026-80668                      CVE-2026-80692 CVE-2026-80693 CVE-2026-80698 CVE-2026-80705                      CVE-2026-80734 CVE-2026-80738 CVE-2026-80747 CVE-2026-80761                      CVE-2026-80786 CVE-2026-80866 CVE-2026-80884 CVE-2026-80905                      CVE-2026-80920 CVE-2026-80948 CVE-2026-89528 CVE-2026-89534                      CVE-2026-89537 CVE-2026-89601 CVE-2026-89631 CVE-2026-89642                      CVE-2026-89648 CVE-2026-89654 CVE-2026-89682 CVE-2026-89705                      CVE-2026-89709 CVE-2026-89757 CVE-2026-89788 CVE-2026-89808                      CVE-2026-89810 CVE-2026-89811 CVE-2026-89812 CVE-2026-89813                      CVE-2026-89833 CVE-2026-89906 CVE-2026-89913 CVE-2026-89920                      CVE-2026-89987 CVE-2026-90061 CVE-2026-90083 CVE-2026-90084                      CVE-2026-90086 CVE-2026-90087 CVE-2026-90093 CVE-2026-90097                      CVE-2026-90099 CVE-2026-90104 CVE-2026-90105 CVE-2026-90106                      CVE-2026-90111 CVE-2026-90116 CVE-2026-90142 CVE-2026-90144                      CVE-2026-90149 CVE-2026-90154 CVE-2026-90155 CVE-2026-90156                      CVE-2026-90161 CVE-2026-90162 CVE-2026-90167 CVE-2026-90174                      CVE-2026-90177 CVE-2026-90179 CVE-2026-90182 CVE-2026-90183                      CVE-2026-90204 CVE-2026-90205 CVE-2026-90206 CVE-2026-90208                      CVE-2026-90217 CVE-2026-90231 CVE-2026-90232 CVE-2026-90234                      CVE-2026-90240 CVE-2026-90247 CVE-2026-90256 CVE-2026-90259                      CVE-2026-90260 CVE-2026-90263 CVE-2026-90264 CVE-2026-90265                      CVE-2026-90267 CVE-2026-90273 CVE-2026-90289 CVE-2026-90300                      CVE-2026-90301 CVE-2026-90311 CVE-2026-90320 CVE-2026-90321                      CVE-2026-90324 CVE-2026-90326 CVE-2026-90328 CVE-2026-90330                      CVE-2026-90333 CVE-2026-90335 CVE-2026-90336 CVE-2026-90337                      CVE-2026-90343 CVE-2026-90345 CVE-2026-90346 CVE-2026-90347                      CVE-2026-90351 CVE-2026-90359 CVE-2026-90363 CVE-2026-90365                      CVE-2026-90367 CVE-2026-90408 CVE-2026-90409 CVE-2026-90417                      CVE-2026-90421 CVE-2026-90422 CVE-2026-90424 CVE-2026-90427                      CVE-2026-92480 CVE-2026-92482 CVE-2026-92485 CVE-2026-92503                      CVE-2026-92520 CVE-2026-93058 CVE-2026-93081 CVE-2026-93100                      CVE-2026-93104 CVE-2026-93105 CVE-2026-93116 CVE-2026-93122                      CVE-2026-93125 CVE-2026-93129 CVE-2026-93144 CVE-2026-93146                      CVE-2026-93148 CVE-2026-93168 CVE-2026-93175 CVE-2026-93176                      CVE-2026-93181 CVE-2026-93202 CVE-2026-93216 CVE-2026-93221                      CVE-2026-93230 CVE-2026-93251 CVE-2026-93260 CVE-2026-93272                      CVE-2026-93282 CVE-2026-97422 CVE-2026-97424 CVE-2026-97432                      CVE-2026-97477 CVE-2026-97478 CVE-2026-97479 CVE-2026-97480                      CVE-2026-97493 CVE-2026-97501 CVE-2026-97503 CVE-2026-97513                      CVE-2026-97515 CVE-2026-97538 CVE-2026-97554 CVE-2026-97561                      CVE-2026-97928 CVE-2026-97960 CVE-2026-97962 CVE-2026-97975                      CVE-2026-97988 CVE-2026-97989 CVE-2026-97997 CVE-2026-98003                      CVE-2026-98019 CVE-2026-98032 CVE-2026-98033 CVE-2026-98034                      CVE-2026-98038 CVE-2026-98043 CVE-2026-98044 CVE-2026-98047                      CVE-2026-98048 CVE-2026-98049 CVE-2026-98053 CVE-2026-98058                      CVE-2026-98062 CVE-2026-98067 CVE-2026-98073 CVE-2026-98079                      CVE-2026-98084 CVE-2026-98085 CVE-2026-98099 CVE-2026-98124                      CVE-2026-98131 CVE-2026-98134 CVE-2026-98147 CVE-2026-98148                      CVE-2026-98156 CVE-2026-98916 CVE-2026-98974 CVE-2026-98975                      CVE-2026-98977 CVE-2026-98981 CVE-2026-98985 CVE-2026-98993                      CVE-2026-99002 CVE-2026-99009 CVE-2026-99014 CVE-2026-99019                      CVE-2026-99027 CVE-2026-99028 CVE-2026-99041 CVE-2026-99044                      CVE-2026-99077 CVE-2026-99082 CVE-2026-99083 CVE-2026-99085                      CVE-2026-99092 CVE-2026-99098 CVE-2026-99100 CVE-2026-99103                      CVE-2026-99105 CVE-2026-99106 CVE-2026-99110 CVE-2026-99112                      CVE-2026-99113 CVE-2026-99114 CVE-2026-99115 CVE-2026-99117                      CVE-2026-99118 CVE-2026-99121 CVE-2026-99123 CVE-2026-99124                      CVE-2026-99126 CVE-2026-99127 CVE-2026-99128 CVE-2026-99130                      CVE-2026-99131 CVE-2026-99132 CVE-2026-99133 CVE-2026-99134                      CVE-2026-99135 CVE-2026-99136 CVE-2026-99138 CVE-2026-99139                      CVE-2026-99140 CVE-2026-99142 CVE-2026-99143 CVE-2026-99147                      CVE-2026-99150 CVE-2026-99152 CVE-2026-99153 CVE-2026-99154                      CVE-2026-99155 CVE-2026-99156 CVE-2026-99157 CVE-2026-99158                      CVE-2026-99159 CVE-2026-99160 CVE-2026-99161 CVE-2026-99163                      CVE-2026-99165 CVE-2026-99166 CVE-2026-99167 CVE-2026-99169                      CVE-2026-99171 CVE-2026-99173 CVE-2026-99174 CVE-2026-99175                      CVE-2026-99176 CVE-2026-99178 CVE-2026-99179 CVE-2026-99180                      CVE-2026-99181 CVE-2026-99182 CVE-2026-99187 CVE-2026-99191                      CVE-2026-99192 CVE-2026-99201 CVE-2026-99202 CVE-2026-99203                      CVE-2026-99204 CVE-2026-99206 CVE-2026-99211 CVE-2026-99212                      CVE-2026-99213 CVE-2026-99214 CVE-2026-99216 CVE-2026-99218                      CVE-2026-99219 CVE-2026-99220 CVE-2026-99221 CVE-2026-99222                      CVE-2026-99223 CVE-2026-99224 CVE-2026-99225 CVE-2026-99226                      CVE-2026-99227 CVE-2026-99228 CVE-2026-99229 CVE-2026-99230                      CVE-2026-99231 CVE-2026-99233 CVE-2026-99234 CVE-2026-99235                      CVE-2026-99236 CVE-2026-99239 CVE-2026-99244 CVE-2026-99245                      CVE-2026-99246 CVE-2026-99247 CVE-2026-99249 CVE-2026-99250                      CVE-2026-99251 CVE-2026-99254 CVE-2026-99255 CVE-2026-99256                      CVE-2026-99258 CVE-2026-99284 CVE-2026-99285 CVE-2026-100072                      CVE-2026-100074 CVE-2026-100076 CVE-2026-100077     Debian Bug     : 1112238 1151097 1151281

    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.115-2~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.114 and 6.12.115.

    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 AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1794643812 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: add HE 6 GHz     capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every     band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements     can fail, triggering the WARN_ON in __ieee80211_start_scan(). (CVE-2026-98328)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix issue in verifying     allow_ptr_leaks After we converted the capabilities of our networking-bpf program from cap_sys_admin to     cap_net_admin+cap_bpf, our networking-bpf program failed to start. Because it failed the bpf verifier, and     the error log is R3 pointer comparison prohibited. A simple reproducer as follows, SEC(cls-ingress)     int ingress(struct __sk_buff *skb) { struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr);
    if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK; } Per discussion with     Yonghong and Alexei [1], comparison of two packet pointers is not a pointer leak. This patch fixes it. Our     local kernel is 6.1.y and we expect this fix to be backported to 6.1.y, so stable is CCed. [1].
    https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/     (CVE-2023-54181)

  - In the Linux kernel, the following vulnerability has been resolved: driver core: Avoid warning when     removing a device while its supplier is unbinding During driver removal, the following warning can appear:
    WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc ... Call trace:
    __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0     device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc     driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90     [lan966x_pci] This warning is triggered when a consumer is removed because the links status of its     supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set. The topology in     terms of consumers/suppliers used was the following (consumer ---> supplier): i2c -----------> OIC ---->     PCI device | ^ | | +---> pinctrl ---+ When the PCI device is removed, the OIC (interrupt controller) has     to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c     need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device In details, the removal     sequence is the following (with 0000:01:00.0 the PCI device): driver_detach: call     device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status =     DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status     = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl):
    links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status     = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND     oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING The     warning is triggered by the i2c removal because the OIC (supplier) links status is not     DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING. It is perfectly legit to have the     links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered     the consumer unbinding and didn't finish yet when the i2c is unbound. Avoid the warning when the supplier     links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings.
    (CVE-2026-97479)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB     altmode array index The UCSI displayport driver indexes the connector's port altmode array with the     GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES     elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not     equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to     verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.
    (CVE-2026-90025)

  - In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on     the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is     still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and     jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved     to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference,     so this happens on the first decrement. out_forget never drains free_me -- only the success path calls     pnfs_free_lseg_list(). Commit 814b84971388 (pNFS/NFSv4: Fix a layout segment leak in     pnfs_layout_process()) added the drain; commit 08bd8dbe8882 (pNFS/NFSv4: Try to return invalid layout in     pnfs_layout_process()) removed it while switching the destination to lo->plh_return_segs, which is     drained elsewhere. Commit fb700ef02676 (NFSv4.1: Simplify layout return in pnfs_layout_process())     switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list()     call. (CVE-2026-89710)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
375340	Linux Distros Unpatched Vulnerability : CVE-2026-99235	Nessus	Misc.	2026/11/2	2026/11/5	high
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	2026/11/10	2026/11/10	high
380301	Debian dla-4904 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	2026/11/13	2026/11/13	high
381298	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1794643812)	Nessus	Alma Linux Local Security Checks	2026/11/14	2026/11/14	high

偵測

搜尋 Plugin

high

high

high

high