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

  - keys: Check the authorization payload in process keyring searches An authorization payload and its saved     credentials must remain valid while search_process_keyrings_rcu() searches the requestor's keyrings. The     function validates the authorization key, then separately loads payload.data[0] and unconditionally reads     rka->cred. Validation does not prevent request_key_auth_revoke() from clearing the payload. A request-key     helper can assume authority and fork a descendant that inherits the authorization key. If the descendant     misses in its own keyrings, it falls back to the saved requestor credentials. Successful target     instantiation invalidates the authorization key without clearing the payload. After the helper exits,     UMH_WAIT_PROC returns to the requester, which calls complete_request_key() and revokes that key. With the     descendant paused after validation, the paths can interleave as follows: 1. The descendant enters     search_process_keyrings_rcu() under RCU and key_validate() succeeds. 2. The helper instantiates the     target, invalidates the authorization key, and exits. 3. The requester resumes from UMH_WAIT_PROC, calls     complete_request_key(), and revokes the authorization key. request_key_auth_revoke() sets its payload     pointer to NULL. 4. The descendant loads NULL and dereferences rka->cred. This NULL dereference can oops     the kernel. RCU delays payload disposal but does not prevent the pointer from being cleared. Load the     payload with dereference_key_rcu() and require a non-NULL result before validating the authorization key     and searching its saved credentials. A non-NULL payload and its credentials remain alive for the caller's     RCU read-side section; a cleared payload skips the fallback search and follows the existing error     selection. KASAN report as below: Oops: general protection fault, probably for non-canonical address     0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range     [0x0000000000000028-0x000000000000002f] RIP: 0010:search_process_keyrings_rcu+0x32b/0x790 (CVE-2026-99225)

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

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1794654433 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: bnxt: fix head underflow on XDP head-     grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also     crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb     head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is     that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at     least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is     adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start =     page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression     subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the     previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb     is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the     right page. In either case, the corrupted reference count can lead to the page being prematurely recycled     while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this     would result in a double free. The commit under fixes updated this code to handle the case where the     native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset     field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate     it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to     compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are     two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at     page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is     called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr     was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with     this commit applied causes the test to run successfully to completion. The other rx_skb_func     implementations don't have this issue. (CVE-2026-74269)

  - 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: smb: client: avoid using uninitialized     SIDs in cifs_posix_to_fattr() cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a     malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server),     posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in     parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes     them to request_key() to construct a SID string, potentially leaking kernel stack contents to the     userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when     parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info'     pointer so they are unaffected. (CVE-2026-97554)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent     states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO:
    rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8     task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec     mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof     alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in     bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on     PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task     never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a     quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] (CVE-2026-89753)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3448 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    mm/pagewalk: fix stale walk->action escaping walk_pmd_range() (CVE-2026-89754)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails (CVE-2026-98863)

    In the Linux kernel, the following vulnerability has been resolved:

    ipv4: udp: Create exceptions before socket matching (CVE-2026-99077)

    In the Linux kernel, the following vulnerability has been resolved:

    workqueue: Fix unbound pool lifetime for pending pwqs (CVE-2026-99103)

    In the Linux kernel, the following vulnerability has been resolved:

    sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ     (CVE-2026-99105)

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix heap overflow in cifs_do_set_acl() (CVE-2026-99110)

    In the Linux kernel, the following vulnerability has been resolved:

    net/sched: cls_flower: validate mask pointer after nla_next() (CVE-2026-99112)

    In the Linux kernel, the following vulnerability has been resolved:

    net: bridge: mcast: don't truncate the port group walk on teardown (CVE-2026-99117)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/i915/dmc: Harden DMC firmware payload parsing (CVE-2026-99118)

    In the Linux kernel, the following vulnerability has been resolved:

    ipv4: avoid divide by zero in fib_rebalance (CVE-2026-99121)

    In the Linux kernel, the following vulnerability has been resolved:

    vsock/virtio: validate packet source for connected sockets (CVE-2026-99123)

    In the Linux kernel, the following vulnerability has been resolved:

    page_pool: keep frag_offset aligned for odd-sized requests (CVE-2026-99127)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: validate chunk length in the inqueue parser (CVE-2026-99128)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/cancel: don't spin on local work the task can't run (CVE-2026-99130)

    In the Linux kernel, the following vulnerability has been resolved:

    xfs: fix capability check in xfs (CVE-2026-99131)

    In the Linux kernel, the following vulnerability has been resolved:

    dm-integrity: fix infinite loop on discard with large tag size (CVE-2026-99135)

    In the Linux kernel, the following vulnerability has been resolved:

    dm-crypt: fix a tiny race condition in crypt_dec_pending (CVE-2026-99136)

    In the Linux kernel, the following vulnerability has been resolved:

    tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO) (CVE-2026-99138)

    In the Linux kernel, the following vulnerability has been resolved:

    tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION) (CVE-2026-99139)

    In the Linux kernel, the following vulnerability has been resolved:

    tracing: Check operator stack capacity before pushing (CVE-2026-99142)

    In the Linux kernel, the following vulnerability has been resolved:

    tracing: Keep the predicate limit separate from program capacity (CVE-2026-99143)

    In the Linux kernel, the following vulnerability has been resolved:

    drm/exec: don't immediately add prelocked obj to array of locked objs (CVE-2026-99147)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: libiscsi: Validate the ITT reflected in a Reject PDU (CVE-2026-99153)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: xen/scsifront: Check for a NULL shadow entry on a backend response (CVE-2026-99155)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: st: Fix use-after-free race between st_remove() and st_open() (CVE-2026-99156)

    In the Linux kernel, the following vulnerability has been resolved:

    ring-buffer: Fix false warning in ring_buffer_map_get_reader() (CVE-2026-99158)

    In the Linux kernel, the following vulnerability has been resolved:

    ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() (CVE-2026-99159)

    In the Linux kernel, the following vulnerability has been resolved:

    ring-buffer: Do not show buffer_meta for CPUs without a buffer (CVE-2026-99160)

    In the Linux kernel, the following vulnerability has been resolved:

    sctp: revalidate output stream after association connect wait (CVE-2026-99165)

    In the Linux kernel, the following vulnerability has been resolved:

    net/sched: fix use-after-free in __tcf_action_put() (CVE-2026-99167)

    In the Linux kernel, the following vulnerability has been resolved:

    futex: Fix mm reuse handling for FUT_OFF_MMSHARED (CVE-2026-99169)

    In the Linux kernel, the following vulnerability has been resolved:

    ntfs3: free the sbi after a grace period (CVE-2026-99171)

    In the Linux kernel, the following vulnerability has been resolved:

    eventfs: Free the eventfs_inode after an rcu grace period too (CVE-2026-99173)

    In the Linux kernel, the following vulnerability has been resolved:

    ext4: free the sbi after a grace period (CVE-2026-99174)

    In the Linux kernel, the following vulnerability has been resolved:

    fsnotify: prevent mark additions during connector teardown (CVE-2026-99175)

    In the Linux kernel, the following vulnerability has been resolved:

    KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry (CVE-2026-99176)

    In the Linux kernel, the following vulnerability has been resolved:

    x86/kvm: Don't consume async #PF flags on a kernel #PF in NMI context (CVE-2026-99178)

    In the Linux kernel, the following vulnerability has been resolved:

    autofs: ignore notification errors from a replaced pipe (CVE-2026-99181)

    In the Linux kernel, the following vulnerability has been resolved:

    perf: Fix perf_pmu_migrate_context() leaving events behind (CVE-2026-99187)

    In the Linux kernel, the following vulnerability has been resolved:

    calipso: keep BIG TCP payload_len in calipso_skbuff_setattr() (CVE-2026-99191)

    In the Linux kernel, the following vulnerability has been resolved:

    netlink: avoid hashing the network namespace pointer (CVE-2026-99201)

    In the Linux kernel, the following vulnerability has been resolved:

    pipe: preserve existing fasync readers on writer setup failure (CVE-2026-99203)

    In the Linux kernel, the following vulnerability has been resolved:

    scsi: target: iscsi: Fix race in discovery auth updates (CVE-2026-99206)

    In the Linux kernel, the following vulnerability has been resolved:

    netlink: reset skb headers before unicast and multicast filtering (CVE-2026-99211)

    In the Linux kernel, the following vulnerability has been resolved:

    vsock: treat TCP_CLOSING as once-established (CVE-2026-99213)

    In the Linux kernel, the following vulnerability has been resolved:

    Drivers: hv: Don't reset VMBus connection state on error/exit paths (CVE-2026-99216)

    In the Linux kernel, the following vulnerability has been resolved:

    coredump: hold RCU while releasing parked threads (CVE-2026-99218)

    In the Linux kernel, the following vulnerability has been resolved:

    ftrace: Initialize modname and offset in print_rec() (CVE-2026-99219)

    In the Linux kernel, the following vulnerability has been resolved:

    asymmetric_keys: reject trust keys without IDs (CVE-2026-99220)

    In the Linux kernel, the following vulnerability has been resolved:

    keys/trusted_keys: return immediately after TPM unseal failure (CVE-2026-99221)

    In the Linux kernel, the following vulnerability has been resolved:

    keys: Protect the read method check against type removal (CVE-2026-99222)

    In the Linux kernel, the following vulnerability has been resolved:

    keys: make keyring indexes independent of kernel addresses (CVE-2026-99223)

    In the Linux kernel, the following vulnerability has been resolved:

    keys: Check the authorization payload in process keyring searches (CVE-2026-99225)

    In the Linux kernel, the following vulnerability has been resolved:

    keys: Avoid the owner account dereference in named keyring lookup (CVE-2026-99226)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/waitid: prevent cancel reference wrap (CVE-2026-99227)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/io-wq: don't lose the signal that ends work (CVE-2026-99228)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/wait: don't spin on a stuck overflow list (CVE-2026-99229)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/waitid: own the request before clearing ->head (CVE-2026-99231)

    In the Linux kernel, the following vulnerability has been resolved:

    tracing: Reject incomplete event filter expressions (CVE-2026-99236)

    In the Linux kernel, the following vulnerability has been resolved:

    pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper (CVE-2026-99244)

    In the Linux kernel, the following vulnerability has been resolved:

    KEYS: Fix key_reject_and_link() race with keyring restriction (CVE-2026-99245)

    In the Linux kernel, the following vulnerability has been resolved:

    tipc: protect node reset trace dump with node lock (CVE-2026-99246)

    In the Linux kernel, the following vulnerability has been resolved:

    tracing: Do not initialize tracefs work if tracing is disabled (CVE-2026-99247)

    In the Linux kernel, the following vulnerability has been resolved:

    pid_namespace: make zap_pid_ns_processes() freezable (CVE-2026-99249)

    In the Linux kernel, the following vulnerability has been resolved:

    printk: Postpone kthread startup (CVE-2026-99250)

    In the Linux kernel, the following vulnerability has been resolved:

    Drivers: hv: Avoid infinite retry loop in init_vp_index() (CVE-2026-99251)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring: don't flood a cancelling task with task_work (CVE-2026-99254)

    In the Linux kernel, the following vulnerability has been resolved:

    io_uring/io-wq: don't hide a link from cancellations (CVE-2026-99255)

    In the Linux kernel, the following vulnerability has been resolved:

    dm cache: fix issue with background work locking (CVE-2026-99256)

    In the Linux kernel, the following vulnerability has been resolved:

    x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() (CVE-2026-99258)

Tenable has extracted the preceding description block directly from the tested product 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 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.

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1794654433 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: bnxt: fix head underflow on XDP head-     grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also     crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb     head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is     that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at     least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is     adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start =     page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression     subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the     previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb     is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the     right page. In either case, the corrupted reference count can lead to the page being prematurely recycled     while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this     would result in a double free. The commit under fixes updated this code to handle the case where the     native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset     field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate     it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to     compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are     two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at     page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is     called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr     was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with     this commit applied causes the test to run successfully to completion. The other rx_skb_func     implementations don't have this issue. (CVE-2026-74269)

  - 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: smb: client: avoid using uninitialized     SIDs in cifs_posix_to_fattr() cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a     malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server),     posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in     parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes     them to request_key() to construct a SID string, potentially leaking kernel stack contents to the     userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when     parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info'     pointer so they are unaffected. (CVE-2026-97554)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent     states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO:
    rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8     task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec     mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof     alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in     bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on     PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task     never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a     quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] (CVE-2026-89753)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
375330	Linux Distros Unpatched Vulnerability : CVE-2026-99225	Nessus	Misc.	2026/11/2	2026/11/2	critical
379844	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-139)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical
381507	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794654433)	Nessus	Rocky Linux Local Security Checks	2026/11/15	2026/11/15	high
379864	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3448)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical
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
379876	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2026-121)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical
381516	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794654433)	Nessus	Alma Linux Local Security Checks	2026/11/15	2026/11/15	high

偵測

搜尋 Plugin

critical

critical

high

critical

high

high

critical

high