Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mtd： part：拒绝 mtd_add_partition（） 中的MTDPART_OFS_RETAIN mtd_add_partition（） 未拒绝 （-3） MTDPART_OFS_RETAIN的特殊偏移值，导致通过 NAND 设备上的 BLKPG ioctl 调用时 add_mtd_device（） 中出现WARN_ON。RETAIN 值取决于 cur_offset 是上一个分区的结尾，但在动态分区路径中cur_offset等于偏移参数本身，从而导致未定义的行为。提交 5daa7b21496a（mtd：为 ioctl 请求准备分区添加和删除函数）引入了 mtd_add_partition（） 并正确拒绝了 MTDPART_OFS_APPEND （-1） 和 MTDPART_OFS_NXTBLK （-2），因为这些特殊偏移依赖于cur_offset跟踪上一个分区的末尾。但是，提交 1a31368bf92e（mtd：为分区添加标记，应只在分区后面留下 smth.）稍后为静态分区表路径添加了 MTDPART_OFS_RETAIN （-3），但未更新 mtd_add_partition（） 以同样拒绝此值。通过 BLKPG 传递 offset=-3 时，allocate_partition（） 中的 RETAIN 大小计算下溢 （parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3）。如果下溢结果似乎没有留下足够空间，allocate_partition（） 会通过 goto 跳至out_register，而跳过擦除大小初始化。这导致 erasesize=0，从而触发：
    WARN_ON（（！mtd->erasesize || ！master->_erase） &; ！（add_mtd_device（） 中的 mtd->flags &; MTD_NO_ERASE））。如果下溢结果似乎留有足够的空间，则会计算虚假的分区大小，但超出范围的健全性检查会捕获无效的偏移，并创建一个禁用的空分区 （offset=0， size=0），而不会返回错误。通过将MTDPART_OFS_RETAIN添加到 mtd_add_partition（） 中的拒绝列表来修复此问题，这与 APPEND 和 NXTBLK 的现有处理一致。（CVE-2026-93048）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

AlmaLinux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1793100968公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：udf: Avoid double brelse() in udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK> invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry() returns NULL. (CVE-2022-50755)

  - 已修复 Linux 内核中的下列漏洞：soc: qcom: qmi_encdec: Restrict string length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - 已修复 Linux 内核中的下列漏洞：can: isotp: check CAN address family in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - 已修复 Linux 内核中的下列漏洞：usb: rndis_host: Secure rndis_query check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently the response pointer will be referring to a location past the expected buffer boundaries allowing information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - 已修复 Linux 内核中的下列漏洞：mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as throughout the code just the erase size is considered to determine whether an erase type is supported or not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Debian 12 主机上存在安装的程序包，该程序包受到 DLA-4841 公告中提及的多个漏洞的影响。

    - ------------------------------------------------------------------------- Debian LTS 公告 DLA-4841-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Salvatore Bonaccorso 2026 年 10 月 17 日 https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    程序包：linux 版本： 6.1.190-1 CVE ID： CVE-2023-52629 CVE-2023-52676 CVE-2023-53231 CVE-2023-53336 CVE-2023-53353 CVE-2023-53429 CVE-2023-53491 CVE-2023-53538 CVE-2023-53574 CVE-2023-53627 CVE-2023-53762 CVE-2023-53851 CVE-2023-53857 CVE-2023-53999 CVE-2023-54227 CVE-2023-54233 CVE-2024-35887 CVE-2024-49568 CVE-2024-50017 CVE-2024-50029 CVE-2024-58097 CVE-2025-21649 CVE-2025-21651 CVE-2025-21759 CVE-2025-22039 CVE-2025-22103 CVE-2025-23129 CVE-2025-37833 CVE-2025-40074 CVE-2025-40097 CVE-2025-68190 CVE-2025-68736 CVE-2026-23191 CVE-2026-23447 CVE-2026-23448 CVE-2026-31420 CVE-2026-43088 CVE-2026-43198 CVE-2026-43288 CVE-2026-45897 CVE-2026-46090 CVE-2026-52944 CVE-2026-52988 CVE-2026-53005 CVE-2026-53078 CVE-2026-64210 CVE-2026-68097 CVE-2026-68161 CVE-2026-68236 CVE-2026-68286 CVE-2026-68287 CVE-2026-68288 CVE-2026-68289 CVE-2026-68391 CVE-2026-72334 CVE-2026-72402 CVE-2026-72413 CVE-2026-74268 CVE-2026-74289 CVE-2026-74294 CVE-2026-74334 CVE-2026-74474 CVE-2026-74496 CVE-2026-74521 CVE-2026-74565 CVE-2026-80521 CVE-2026-80671 CVE-2026-80689 CVE-2026-80833 CVE-2026-80834 CVE-2026-80912 CVE-2026-80914 CVE-2026-80928 CVE-2026-80930 CVE-2026-80931 CVE-2026-80932 CVE-2026-80938 CVE-2026-80941 CVE-2026-80944 CVE-2026-80949 CVE-2026-80951 CVE-2026-80952 CVE-2026-80963 CVE-2026-80964 CVE-2026-80965 CVE-2026-80966 CVE-2026-80967 CVE-2026-80968 CVE-2026-80969 CVE-2026-80971 CVE-2026-80972 CVE-2026-80973 CVE-2026-80976 CVE-2026-80977 CVE-2026-80978 CVE-2026-80982 CVE-2026-80983 CVE-2026-80987 CVE-2026-80988 CVE-2026-80992 CVE-2026-80994 CVE-2026-81000 CVE-2026-81001 CVE-2026-81002 CVE-2026-81003 CVE-2026-81005 CVE-2026-81007 CVE-2026-81008 CVE-2026-81017 CVE-2026-89440 CVE-2026-89444 CVE-2026-89456 CVE-2026-89457 CVE-2026-89458 CVE-2026-89461 CVE-2026-89463 CVE-2026-89464 CVE-2026-89469 CVE-2026-89470 CVE-2026-89471 CVE-2026-89474 CVE-2026-89475 CVE-2026-89476 CVE-2026-89477 CVE-2026-89478 CVE-2026-89479 CVE-2026-89480 CVE-2026-89481 CVE-2026-89482 CVE-2026-89483 CVE-2026-89485 CVE-2026-89487 CVE-2026-89488 CVE-2026-89489 CVE-2026-89490 CVE-2026-89491 CVE-2026-89493 CVE-2026-89494 CVE-2026-89495 CVE-2026-89496 CVE-2026-89497 CVE-2026-89498 CVE-2026-89504 CVE-2026-89508 CVE-2026-89510 CVE-2026-89511 CVE-2026-89512 CVE-2026-89515 CVE-2026-89524 CVE-2026-89525 CVE-2026-89532 CVE-2026-89533 CVE-2026-89538 CVE-2026-89540 CVE-2026-89541 CVE-2026-89542 CVE-2026-89548 CVE-2026-89549 CVE-2026-89551 CVE-2026-89554 CVE-2026-89555 CVE-2026-89557 CVE-2026-89559 CVE-2026-89560 CVE-2026-89562 CVE-2026-89563 CVE-2026-89565 CVE-2026-89569 CVE-2026-89573 CVE-2026-89575 CVE-2026-89576 CVE-2026-89579 CVE-2026-89582 CVE-2026-89583 CVE-2026-89585 CVE-2026-89586 CVE-2026-89587 CVE-2026-89594 CVE-2026-89595 CVE-2026-89596 CVE-2026-89597 CVE-2026-89599 CVE-2026-89604 CVE-2026-89605 CVE-2026-89606 CVE-2026-89607 CVE-2026-89608 CVE-2026-89609 CVE-2026-89615 CVE-2026-89616 CVE-2026-89617 CVE-2026-89621 CVE-2026-89626 CVE-2026-89627 CVE-2026-89628 CVE-2026-89634 CVE-2026-89636 CVE-2026-89640 CVE-2026-89643 CVE-2026-89649 CVE-2026-89650 CVE-2026-89653 CVE-2026-89655 CVE-2026-89656 CVE-2026-89662 CVE-2026-89663 CVE-2026-89665 CVE-2026-89669 CVE-2026-89674 CVE-2026-89684 CVE-2026-89694 CVE-2026-89696 CVE-2026-89697 CVE-2026-89699 CVE-2026-89704 CVE-2026-89706 CVE-2026-89710 CVE-2026-89711 CVE-2026-89712 CVE-2026-89720 CVE-2026-89723 CVE-2026-89724 CVE-2026-89725 CVE-2026-89726 CVE-2026-89729 CVE-2026-89730 CVE-2026-89732 CVE-2026-89733 CVE-2026-89736 CVE-2026-89741 CVE-2026-89742 CVE-2026-89744 CVE-2026-89746 CVE-2026-89749 CVE-2026-89751 CVE-2026-89752 CVE-2026-89753 CVE-2026-89756 CVE-2026-89765 CVE-2026-89776 CVE-2026-89777 CVE-2026-89778 CVE-2026-89779 CVE-2026-89780 CVE-2026-89781 CVE-2026-89782 CVE-2026-89783 CVE-2026-89784 CVE-2026-89785 CVE-2026-89786 CVE-2026-89787 CVE-2026-89789 CVE-2026-89792 CVE-2026-89796 CVE-2026-89816 CVE-2026-89817 CVE-2026-89818 CVE-2026-89821 CVE-2026-89822 CVE-2026-89823 CVE-2026-89824 CVE-2026-89843 CVE-2026-89845 CVE-2026-89846 CVE-2026-89847 CVE-2026-89849 CVE-2026-89850 CVE-2026-89851 CVE-2026-89852 CVE-2026-89853 CVE-2026-89854 CVE-2026-89855 CVE-2026-89856 CVE-2026-89858 CVE-2026-89861 CVE-2026-89863 CVE-2026-89864 CVE-2026-89865 CVE-2026-89870 CVE-2026-89871 CVE-2026-89872 CVE-2026-89876 CVE-2026-89877 CVE-2026-89878 CVE-2026-89879 CVE-2026-89880 CVE-2026-89881 CVE-2026-89883 CVE-2026-89887 CVE-2026-89888 CVE-2026-89890 CVE-2026-89891 CVE-2026-89892 CVE-2026-89893 CVE-2026-89894 CVE-2026-89895 CVE-2026-89896 CVE-2026-89897 CVE-2026-89901 CVE-2026-89922 CVE-2026-89923 CVE-2026-89924 CVE-2026-89925 CVE-2026-89926 CVE-2026-89927 CVE-2026-89930 CVE-2026-89932 CVE-2026-89936 CVE-2026-89937 CVE-2026-89939 CVE-2026-89945 CVE-2026-89946 CVE-2026-89947 CVE-2026-89948 CVE-2026-89949 CVE-2026-89951 CVE-2026-89952 CVE-2026-89953 CVE-2026-89954 CVE-2026-89957 CVE-2026-89959 CVE-2026-89964 CVE-2026-89965 CVE-2026-89968 CVE-2026-89969 CVE-2026-89970 CVE-2026-89973 CVE-2026-89979 CVE-2026-89980 CVE-2026-89982 CVE-2026-89983 CVE-2026-89984 CVE-2026-89988 CVE-2026-89989 CVE-2026-89992 CVE-2026-89993 CVE-2026-89997 CVE-2026-89998 CVE-2026-89999 CVE-2026-90000 CVE-2026-90003 CVE-2026-90007 CVE-2026-90011 CVE-2026-90015 CVE-2026-90017 CVE-2026-90018 CVE-2026-90019 CVE-2026-90020 CVE-2026-90025 CVE-2026-90031 CVE-2026-90032 CVE-2026-90033 CVE-2026-90034 CVE-2026-90049 CVE-2026-90053 CVE-2026-90054 CVE-2026-90055 CVE-2026-90056 CVE-2026-90057 CVE-2026-90058 CVE-2026-90060 CVE-2026-90062 CVE-2026-90063 CVE-2026-90067 CVE-2026-90068 CVE-2026-90070 CVE-2026-90071 CVE-2026-90072 CVE-2026-90073 CVE-2026-90074 CVE-2026-90075 CVE-2026-90078 CVE-2026-90081 CVE-2026-90088 CVE-2026-90090 CVE-2026-90091 CVE-2026-90092 CVE-2026-90102 CVE-2026-90103 CVE-2026-90107 CVE-2026-90108 CVE-2026-90110 CVE-2026-90114 CVE-2026-90122 CVE-2026-90124 CVE-2026-90126 CVE-2026-90128 CVE-2026-90140 CVE-2026-90141 CVE-2026-90143 CVE-2026-90151 CVE-2026-90157 CVE-2026-90160 CVE-2026-90176 CVE-2026-90180 CVE-2026-90184 CVE-2026-90185 CVE-2026-90186 CVE-2026-90188 CVE-2026-90189 CVE-2026-90190 CVE-2026-90194 CVE-2026-90196 CVE-2026-90198 CVE-2026-90202 CVE-2026-90203 CVE-2026-90207 CVE-2026-90209 CVE-2026-90214 CVE-2026-90216 CVE-2026-90218 CVE-2026-90219 CVE-2026-90221 CVE-2026-90222 CVE-2026-90223 CVE-2026-90224 CVE-2026-90225 CVE-2026-90226 CVE-2026-90228 CVE-2026-90245 CVE-2026-90248 CVE-2026-90249 CVE-2026-90251 CVE-2026-90253 CVE-2026-90254 CVE-2026-90255 CVE-2026-90257 CVE-2026-90274 CVE-2026-90281 CVE-2026-90283 CVE-2026-90284 CVE-2026-90285 CVE-2026-90286 CVE-2026-90287 CVE-2026-90290 CVE-2026-90292 CVE-2026-90293 CVE-2026-90294 CVE-2026-90295 CVE-2026-90296 CVE-2026-90297 CVE-2026-90298 CVE-2026-90302 CVE-2026-90303 CVE-2026-90307 CVE-2026-90309 CVE-2026-90314 CVE-2026-90316 CVE-2026-90318 CVE-2026-90319 CVE-2026-90327 CVE-2026-90329 CVE-2026-90334 CVE-2026-90341 CVE-2026-90348 CVE-2026-90352 CVE-2026-90353 CVE-2026-90354 CVE-2026-90357 CVE-2026-90360 CVE-2026-90361 CVE-2026-90362 CVE-2026-90372 CVE-2026-90378 CVE-2026-90382 CVE-2026-90386 CVE-2026-90388 CVE-2026-90391 CVE-2026-90393 CVE-2026-90394 CVE-2026-90395 CVE-2026-90403 CVE-2026-90411 CVE-2026-90413 CVE-2026-90414 CVE-2026-90415 CVE-2026-90416 CVE-2026-90419 CVE-2026-90420 CVE-2026-90431 CVE-2026-90434 CVE-2026-90435 CVE-2026-92476 CVE-2026-92477 CVE-2026-92481 CVE-2026-92494 CVE-2026-92496 CVE-2026-92498 CVE-2026-92501 CVE-2026-92504 CVE-2026-92507 CVE-2026-92508 CVE-2026-92509 CVE-2026-92510 CVE-2026-92511 CVE-2026-92512 CVE-2026-92514 CVE-2026-92521 CVE-2026-92522 CVE-2026-92523 CVE-2026-92524 CVE-2026-92525 CVE-2026-93037 CVE-2026-93039 CVE-2026-93040 CVE-2026-93041 CVE-2026-93046 CVE-2026-93048 CVE-2026-93049 CVE-2026-93050 CVE-2026-93051 CVE-2026-93052 CVE-2026-93053 CVE-2026-93054 CVE-2026-93055 CVE-2026-93056 CVE-2026-93061 CVE-2026-93063 CVE-2026-93064 CVE-2026-93067 CVE-2026-93073 CVE-2026-93095 CVE-2026-93098 CVE-2026-93102 CVE-2026-93103 CVE-2026-93108 CVE-2026-93109 CVE-2026-93110 CVE-2026-93114 CVE-2026-93115 CVE-2026-93117 CVE-2026-93118 CVE-2026-93120 CVE-2026-93130 CVE-2026-93131 CVE-2026-93136 CVE-2026-93137 CVE-2026-93138 CVE-2026-93140 CVE-2026-93141 CVE-2026-93142 CVE-2026-93145 CVE-2026-93149 CVE-2026-93151 CVE-2026-93152 CVE-2026-93158 CVE-2026-93159 CVE-2026-93160 CVE-2026-93161 CVE-2026-93165 CVE-2026-93167 CVE-2026-93170 CVE-2026-93177 CVE-2026-93178 CVE-2026-93182 CVE-2026-93183 CVE-2026-93185 CVE-2026-93188 CVE-2026-93189 CVE-2026-93190 CVE-2026-93191 CVE-2026-93203 CVE-2026-93204 CVE-2026-93206 CVE-2026-93210 CVE-2026-93213 CVE-2026-93214 CVE-2026-93219 CVE-2026-93222 CVE-2026-93226 CVE-2026-93234 CVE-2026-93236 CVE-2026-93242 CVE-2026-93245 CVE-2026-93247 CVE-2026-93252 CVE-2026-93256 CVE-2026-93261 CVE-2026-93262 CVE-2026-93264 CVE-2026-93268 CVE-2026-93271 CVE-2026-93274 CVE-2026-93278 CVE-2026-93279 CVE-2026-93280 CVE-2026-93281 CVE-2026-93283 CVE-2026-93286 CVE-2026-93287 CVE-2026-93288 CVE-2026-93781 CVE-2026-93782 CVE-2026-93783 CVE-2026-93784 CVE-2026-93785 CVE-2026-93787 CVE-2026-93788 CVE-2026-93789 CVE-2026-93795 CVE-2026-93797 CVE-2026-93798 CVE-2026-93800 CVE-2026-93802 CVE-2026-93803 CVE-2026-93805 CVE-2026-93806 CVE-2026-93807 CVE-2026-93808 CVE-2026-93810 CVE-2026-93811 CVE-2026-93812 CVE-2026-93813 CVE-2026-93814 CVE-2026-93815 CVE-2026-93816 CVE-2026-93819 CVE-2026-93820 CVE-2026-93821 CVE-2026-93822 CVE-2026-93824 CVE-2026-93825 CVE-2026-93826 CVE-2026-93830 CVE-2026-97407 CVE-2026-97408 CVE-2026-97411 CVE-2026-97413 CVE-2026-97415 CVE-2026-97416 CVE-2026-97417 CVE-2026-97418 CVE-2026-97419 CVE-2026-97420 CVE-2026-97421 CVE-2026-97427 CVE-2026-97430 CVE-2026-97434 CVE-2026-97435 CVE-2026-97436 CVE-2026-97437 CVE-2026-97438 CVE-2026-97439 CVE-2026-97440 CVE-2026-97441 CVE-2026-97442 CVE-2026-97444 CVE-2026-97445 CVE-2026-97446 CVE-2026-97448 CVE-2026-97449 CVE-2026-97450 CVE-2026-97451 CVE-2026-97452 CVE-2026-97453 CVE-2026-97454 CVE-2026-97455 CVE-2026-97456 CVE-2026-97472 CVE-2026-97475 CVE-2026-97476 CVE-2026-97481 CVE-2026-97482 CVE-2026-97483 CVE-2026-97484 CVE-2026-97485 CVE-2026-97486 CVE-2026-97487 CVE-2026-97488 CVE-2026-97489 CVE-2026-97490 CVE-2026-97491 CVE-2026-97492 CVE-2026-97495 CVE-2026-97497 CVE-2026-97502 CVE-2026-97506 CVE-2026-97507 CVE-2026-97508 CVE-2026-97509 CVE-2026-97510 CVE-2026-97516 CVE-2026-97517 CVE-2026-97523 CVE-2026-97524 CVE-2026-97539 CVE-2026-97540 CVE-2026-97541 CVE-2026-97556 CVE-2026-97557 CVE-2026-97564 CVE-2026-97568 CVE-2026-97572 CVE-2026-97573 CVE-2026-97576 CVE-2026-97581 CVE-2026-97582 CVE-2026-97592 CVE-2026-97596 CVE-2026-97598 CVE-2026-97601 CVE-2026-97604 CVE-2026-97608 CVE-2026-97611 CVE-2026-97612 CVE-2026-97899 CVE-2026-97904 CVE-2026-97905 CVE-2026-97909 CVE-2026-97910 CVE-2026-97920 CVE-2026-97921 CVE-2026-97922 CVE-2026-97923 CVE-2026-97925 CVE-2026-97926 CVE-2026-97927 CVE-2026-97930 CVE-2026-97931 CVE-2026-97940 CVE-2026-97948 CVE-2026-97951 CVE-2026-97952 CVE-2026-97954 CVE-2026-97957 CVE-2026-97958 CVE-2026-97959 CVE-2026-97963 CVE-2026-97964 CVE-2026-97969 CVE-2026-97970 CVE-2026-97973 CVE-2026-97977 CVE-2026-97979 CVE-2026-97981 CVE-2026-97982 CVE-2026-97986 CVE-2026-97987 CVE-2026-97991 CVE-2026-97993 CVE-2026-97995 CVE-2026-97998 CVE-2026-98006 CVE-2026-98008 CVE-2026-98009 CVE-2026-98010 CVE-2026-98011 CVE-2026-98012 CVE-2026-98013 CVE-2026-98014 CVE-2026-98015 CVE-2026-98016 CVE-2026-98017 CVE-2026-98022 CVE-2026-98023 CVE-2026-98025 CVE-2026-98027 CVE-2026-98030 CVE-2026-98031 CVE-2026-98046 CVE-2026-98055 CVE-2026-98063 CVE-2026-98064 CVE-2026-98066 CVE-2026-98068 CVE-2026-98069 CVE-2026-98070 CVE-2026-98071 CVE-2026-98072 CVE-2026-98074 CVE-2026-98075 CVE-2026-98076 CVE-2026-98077 CVE-2026-98078 CVE-2026-98080 CVE-2026-98088 CVE-2026-98089 CVE-2026-98090 CVE-2026-98091 CVE-2026-98092 CVE-2026-98094 CVE-2026-98095 CVE-2026-98096 CVE-2026-98098 CVE-2026-98104 CVE-2026-98108 CVE-2026-98113 CVE-2026-98116 CVE-2026-98121 CVE-2026-98123 CVE-2026-98128 CVE-2026-98129 CVE-2026-98130 CVE-2026-98154 CVE-2026-98157 CVE-2026-98158 CVE-2026-98159 CVE-2026-98160 CVE-2026-98167 CVE-2026-98169 CVE-2026-98171 CVE-2026-98172 CVE-2026-98181 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187 CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191 CVE-2026-98194 CVE-2026-98195 CVE-2026-98196 CVE-2026-98197 CVE-2026-98199 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203 CVE-2026-98204 CVE-2026-98205 CVE-2026-98207 CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98213 CVE-2026-98217 CVE-2026-98221 CVE-2026-98227 CVE-2026-98233 CVE-2026-98234 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238 CVE-2026-98239 CVE-2026-98241 CVE-2026-98246 CVE-2026-98247 CVE-2026-98249 CVE-2026-98251 CVE-2026-98252 CVE-2026-98253 CVE-2026-98255 CVE-2026-98257 CVE-2026-98260 CVE-2026-98262 CVE-2026-98264 CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282 CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98298 CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302 CVE-2026-98303 CVE-2026-98306 CVE-2026-98308 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322 CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98328 CVE-2026-98331 CVE-2026-98339 CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344 CVE-2026-98345 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-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370 CVE-2026-98374 CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381 CVE-2026-98383 CVE-2026-98388 CVE-2026-98398 CVE-2026-98402 CVE-2026-98404 CVE-2026-98406 CVE-2026-98407 CVE-2026-98410 CVE-2026-98413 CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421 CVE-2026-98422 CVE-2026-98423 CVE-2026-98426 CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432 CVE-2026-99999 CVE-2026-100070 CVE-2026-100071 CVE-2026-100075 CVE-2026-100078 Debian 缺陷：1108860

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于 Debian 12 bookworm，这些问题已在版本 6.1.190-1中修复。

    建议您升级 linux 程序包。

    如需了解 linux 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux

    有关 Debian LTS 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://wiki.debian.org/LTS

Tenable 已直接从 Debian 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

如 TuxCare ALMALINUX9.6：CLSA-2026：1793100968公告所述，Rocky Linux 9.6 主机上安装的程序包受到多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：udf: Avoid double brelse() in udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK> invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry() returns NULL. (CVE-2022-50755)

  - 已修复 Linux 内核中的下列漏洞：soc: qcom: qmi_encdec: Restrict string length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - 已修复 Linux 内核中的下列漏洞：can: isotp: check CAN address family in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - 已修复 Linux 内核中的下列漏洞：usb: rndis_host: Secure rndis_query check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently the response pointer will be referring to a location past the expected buffer boundaries allowing information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - 已修复 Linux 内核中的下列漏洞：mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as throughout the code just the erase size is considered to determine whether an erase type is supported or not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

CentOS Linux 7 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS7：CLSA-2026：2026：1792976962公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：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)

  - 已修复 Linux 内核中的下列漏洞：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)

  - 已修复 Linux 内核中的下列漏洞：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)

  - 已修复 Linux 内核中的下列漏洞：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)

  - 已修复 Linux 内核中的下列漏洞：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)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
366741	Amazon Linux 2：内核 (ALASKERNEL-5.10-2026-135)	Nessus	Amazon Linux Local Security Checks	2026/10/17	2026/10/22	medium
347646	Linux Distros 未修补的漏洞：CVE-2026-93048	Nessus	Misc.	2026/9/18	2026/10/29	medium
351155	Debian dsa-6528：ata-modules-6.12.111+deb13-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/9/29	2026/9/29	high
362907	Debian dla-4817：ata-modules-6.12.107+deb12-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/4	2026/10/4	high
364137	Oracle Linux 10 / 9：Unbreakable Enterprise 内核 (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
373062	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1793100968）	Nessus	Alma Linux Local Security Checks	2026/10/28	2026/10/28	high
366919	Debian dla-4841：ata-modules-6.1.0-53-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/10/17	2026/10/17	high
373068	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1793100968）	Nessus	Rocky Linux Local Security Checks	2026/10/28	2026/10/28	high
374124	CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞（CENTOS7：CLSA-2026：1792976962）	Nessus	CentOS Local Security Checks	2026/10/30	2026/10/30	high
365258	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/29	high
365279	Amazon Linux 2023：bpftool6.12、kernel6.12、kernel6.12-devel （ALAS2023-2026-3196）	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/22	medium

检测

插件搜索

medium

medium

high

high

high

high

high

high

high

high

medium