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

  - In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report     buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it     during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted     report. (CVE-2024-50302)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-     bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that     exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-     of-bounds accesses later, e.g. in usb_destroy_configuration. (CVE-2024-53197)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace     cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid,     creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can     also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied     without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to     request the key. (CVE-2026-46243)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access     bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same     socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial     Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework     bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking     the child socket. (CVE-2026-52918)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP     rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind     skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is     addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking     skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would     reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender     hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to     skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only     safely reads the ARP header; it does not make the later sender hardware address range writable. If that     range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits()     maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable     before reading the ARP header and before calling skb_store_bits(). (CVE-2026-53266)

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

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

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

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

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

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
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
367921	CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1791949745)	Nessus	CentOS Local Security Checks	2026/10/20	2026/11/13	high
374124	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792976962)	Nessus	CentOS Local Security Checks	2026/10/30	2026/10/30	high

偵測

搜尋 Plugin

high

high

high