遠端 Debian 13 主機已安裝的套件會受到 dsa-6568 公告中提及的多個弱點影響。

    - ------------------------------------------------------------------------- Debian安全公告 DSA-6568-1 security@debian.org https://www.debian.org/security/Salvatore Bonaccorso 2026 年 10 月 16 日 https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    套件 ： 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 錯誤 ： 1149499 1149564 1150891

    在 Linux 核心中發現數個弱點，這些弱點可能會導致特權提升、拒絕服務或資訊洩漏。

    針對穩定的發行版本 (trixie)，已在第 6.12.113-1 版中修復這些問題。

    建議您升級 linux 套件。

    如需有關 linux 安全性狀態的詳細資訊，請參閱其安全追蹤頁面：
    https://security-tracker.debian.org/tracker/linux

    有關 Debian 安全公告、如何將這些更新套用至您的系統以及常見問題的詳細資訊，請參閱：https://www.debian.org/security/

    郵寄清單：debian-security-announce@lists.debian.org

Tenable 已直接從 Debian 安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1792243729 公告中提及的多個弱點影響。

  - 在 5.14.15 版之前的 Linux 核心中發現一個問題。drivers/isdn/capi/kcapi.c 的 detach_capi_ctr 函式中存在一個 array-index-out-of-bounds 缺陷。(CVE-2021-43389)

  - 已解決 Linux 核心中的下列弱點：isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, kcmtpd_ctr_%d, session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ?
    __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] (CVE-2021-4439)

  - 已解決 Linux 核心中的下列弱點：Drivers: hv: vmbus: Use after free in
    __vmbus_open() The open_info variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees open_info without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. (CVE-2021-47049)

  - 已解決 Linux 核心中的下列弱點：scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. (CVE-2021-47565)

  - 已解決 Linux 核心中的下列弱點：igbvf: fix double free in `igbvf_probe` In `igbvf_probe`, if register_netdev() fails, the program will go to label err_hw_init, and then to label err_ioremap. In free_netdev() which is just below label err_ioremap, there is `list_for_each_entry_safe` and `netif_napi_del` which aims to delete all entries in `dev->napi_list`. The program has added an entry `adapter->rx_ring->napi` which is added by `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has been freed below label err_hw_init. So this a UAF. In terms of how to patch the problem, we can refer to igbvf_remove() and delete the entry before `adapter->rx_ring`. The KASAN logs are as follows: [ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450 [ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366 [35.128360] [ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [35.131749] Call Trace: [ 35.132199] dump_stack_lvl+0x59/0x7b [ 35.132865] print_address_description+0x7c/0x3b0 [ 35.133707] ? free_netdev+0x1fd/0x450 [ 35.134378]
    __kasan_report+0x160/0x1c0 [ 35.135063] ? free_netdev+0x1fd/0x450 [ 35.135738] kasan_report+0x4b/0x70 [35.136367] free_netdev+0x1fd/0x450 [ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf] [ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf] [ 35.138751] local_pci_probe+0x13c/0x1f0 [ 35.139461] pci_device_probe+0x37e/0x6c0 [ 35.165526] [ 35.165806] Allocated by task 366: [ 35.166414]
    ____kasan_kmalloc+0xc4/0xf0 [ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf] [ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf] [ 35.168866] local_pci_probe+0x13c/0x1f0 [ 35.169565] pci_device_probe+0x37e/0x6c0 [ 35.179713] [ 35.179993] Freed by task 366: [ 35.180539] kasan_set_track+0x4c/0x80 [ 35.181211] kasan_set_free_info+0x1f/0x40 [ 35.181942]
    ____kasan_slab_free+0x103/0x140 [ 35.182703] kfree+0xe3/0x250 [ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf] [ 35.184040] local_pci_probe+0x13c/0x1f0 (CVE-2021-47589)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1792243434 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：ethernet: hisilicon: hns:
    hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
    because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns. (CVE-2021-47548)

  - 已解決 Linux 核心中的下列弱點：SUNRPC: Fix a suspicious RCU usage warning I received the following warning while running cthon against an ontap server running pNFS: [57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] <TASK> [57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ?
    __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ?
    __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969]
    __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX:
    0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP:
    00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007f ---truncated--- (CVE-2023-52623)

  - 已解決 Linux 核心中的下列弱點：dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the hash_list entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the resume and postsuspend methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP:
    0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX:
    000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10:
    0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ?
    __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]--- (CVE-2024-26880)

  - 已解決 Linux 核心中的下列弱點：netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e (netfilter: nf_tables: flush pending destroy work before netlink notifier) to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ?
    __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ?
    __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750]
    __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953]
    ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036]
    __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list
    *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list);
    11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat
    ---truncated--- (CVE-2024-35899)

  - 已解決 Linux 核心中的下列弱點：drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. (CVE-2024-35950)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - scsi：qla2xxx：修正佇列拆卸時 qpair 工作的釋放後使用 回應佇列 MSI-X 處理常式 qla2xxx_msix_rsp_q（） 透過 queue_work（ha->wq， &qpair->q_work） 安排 qla_do_work（）。qla_do_work（） 解除參照 qpair （vha， rsp） 並採用 qpair->qp_lock。在拆卸過程中，qla2xxx_delete_qpair（） 刪除回應佇列，該佇列呼叫 qla25xx_free_rsp_que（） 中的 free_irq（），然後釋放佇列和 qpair。free_irq（） 會等待執行 hardirq 處理常式，但不會取消已放置在 ha->wq 上的工作。然後，仍在擱置中的q_work會針對釋放的 qpair 和回應佇列執行 qla_do_work（），導致釋放後使用。在完全轉接器拆卸期間尤其可能發生這種情況，其中 destroy_workqueue（ha->wq） 會在佇列配對釋放後強制執行擱置中的工作。在 free_irq（） 釋放中斷之後 （因此無法將任何新工作排入佇列） 之前，以及在釋放回應佇列和 qpair 記憶體之前 （因此排清的處理常式仍會看到有效記憶體） 之前，使用 qla25xx_free_rsp_que（） 中的 cancel_work_sync（） 排清工作項目。保護 rsp->qpair 和 ha->wq 以符合 INIT_WORK（） 條件，並避免在未初始化的work_struct上運作。（CVE-2026-97536）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

ID	名稱	產品	系列	已發布	已更新	嚴重性
366507	Debian dsa-6568 ： ata-modules-6.12.111+deb13-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/10/16	2026/10/16	medium
366779	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers 等多個弱點（CENTOS8.4：CLSA-2026：1792243729）	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/17	high
366778	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1792243434）	Nessus	Alma Linux Local Security Checks	2026/10/17	2026/10/17	medium
350681	Linux Distros 未修補弱點：CVE-2026-97536	Nessus	Misc.	2026/9/25	2026/10/5	high

偵測

搜尋 Plugin

medium

high

medium

high