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

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between     dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read     inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run     from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent     ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s     the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait     for them and the old array can be freed while they still index into it, causing a use-after-free. The     dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take     rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-     after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr     ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do     (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg     (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ...
    Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-     memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do     (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception (CVE-2026-64189)

  - In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to     region_count overflow The local variable region_count in create_log_context() is declared as unsigned int     (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently     large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is     then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far     smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit,     log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing     out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a     mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero'     dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \     /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297,     because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1     1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-     worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive     fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit     overflow check before the value is assigned to lc->region_count. (CVE-2026-53059)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop     ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route()     can move a still-linked walker into that same state when the current leaf is the last route at the root,     so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while     it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed     walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing     w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same     stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only     widens the race. (CVE-2026-97940)

  - In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on     permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which     results in bypassing the permission check. Fix by skipping over detached marks that are not in the current     group. (CVE-2026-46150)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in     nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set     specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace,     nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no     block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set     is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is     enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the     command with Invalid Field when the namespace is not backed by a block device. (CVE-2026-90228)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst     refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong     because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers     the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and     checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following     refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134     [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm:
    ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX,     1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8     85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc     01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP:
    0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000     RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08:
    0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000     R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000)     GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge]
    __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa     [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ?     br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ?     vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
    __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2
    __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa     gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140     napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9     net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ?     smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6     ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1     dst_release underflow (CVE-2021-47222)

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst null     pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the     tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a     grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking.
    Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make     sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we     don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked     in the egress path. (CVE-2021-47223)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit     overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain,     instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset.
    The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset     either comes from an instruction (in which case it is 16 bit), from another register (in which case the     caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can     be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being     up to an u32, it appears that we were open to overflowing the `int`s which were currently used for     arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf     /verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e     9/kernel/bpf/verifier.c#L11904 (CVE-2023-52676)

  - In the Linux kernel, the following vulnerability has been resolved: cifs: fix session state check in     reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because     it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it     complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: Fix use-after-free when volume     resizing failed There is an use-after-free problem reported by KASAN:
    ================================================================== BUG: KASAN: use-after-free in     ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2     PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard     PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44     print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi]     ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record()     returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is     holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and     vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by     not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume     resizing. (CVE-2023-53800)

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 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6568 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6568-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     October 16, 2026                      https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     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-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 the stable distribution (trixie), these problems have been fixed in     version 6.12.113-1.

    We recommend that you upgrade your linux packages.

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

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

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 CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1792234299 advisory.

  - nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote     attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte     nfta_payload attribute, an skb_pull can encounter a negative skb->len. (CVE-2022-36946)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory     corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct     ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is     fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct     ieee80211_channel'. So only 1 element is allocated in this array. When doing:
    mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the     'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void
    *)((u8 *)mvm->nvm_data->channels + 1); because of the (u8 *) cast, we add only 1 to the address of the     beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just     after. Remove the spurious casting so that the pointer arithmetic works as expected. (CVE-2023-52531)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1     intercepts when completing userspace I/O When completing emulation of instruction that generated a     userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction     execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies     the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted     despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is     completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended     recipient) can reach the code in question. gp_interception()'s use is mutually exclusive with     is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with     EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception     during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due     to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at     arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass     CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware     name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170     [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610     [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm]
    __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>     (CVE-2025-40026)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free     on registration failure Make sure to release the sibling interfaces in case controller registration fails     to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by     Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. (CVE-2026-64471)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the     sample count to the packet payload isight_packet() takes the frame count from the device iso packet and     checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if     (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso     header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples()     then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 *     MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past     MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area.
    The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET     keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches     this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate. (CVE-2026-64483)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
377778	Ubuntu 20.04 LTS / 22.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-8963-1)	Nessus	Ubuntu Local Security Checks	2026/11/9	2026/11/13	high
381201	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:22266-1)	Nessus	SuSE Local Security Checks	2026/11/14	2026/11/14	high
371426	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792762308)	Nessus	Alma Linux Local Security Checks	2026/10/23	2026/11/12	high
371988	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1792979985)	Nessus	CentOS Local Security Checks	2026/10/26	2026/11/2	high
379474	SUSE SLES16: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:24662-1)	Nessus	SuSE Local Security Checks	2026/11/12	2026/11/12	high
379497	SUSE SLES16 Security Update : kernel (SUSE-SU-2026:24651-1)	Nessus	SuSE Local Security Checks	2026/11/12	2026/11/12	high
366507	Debian dsa-6568 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	2026/10/16	2026/10/19	high
369489	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792234299)	Nessus	CentOS Local Security Checks	2026/10/21	2026/11/13	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high