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 公告中提及的多個弱點影響。

    - ------------------------------------------------------------------------- Bonaccorso debian-lts@lists.debian.org Debian https://www.debian.org/lts/security/Salvatore LTS 公告 DLA-4841-1 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 書蟲來說，這些問題已經在版本 6.1.190-1中修復了。

    建議您升級 linux 套件。

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

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

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

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

Rocky Linux 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

CentOS Linux 7 主機已安裝的套件會受到 TuxCare CENTOS7：CLSA-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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

  - MTD： 部分：拒絕 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 要求準備分割區 add 和 del 函式） 引入了 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））。如果反向溢位結果似乎留下足夠的空間，則會計算虛假的分割區大小，但超出範圍的健全性檢查會擷取無效的位移，並建立已停用的空白分割區 （位移=0，大小=0），而不是傳回錯誤。透過將MTDPART_OFS_RETAIN新增至 mtd_add_partition（） 中的拒絕清單來修正此問題，這與 APPEND 和 NXTBLK 的現有處理方式一致。（CVE-2026-93048）

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
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 / etc 多個弱點（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 / etc 多個弱點（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 / etc多個弱點（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
366741	Amazon Linux 2：kernel (ALASKERNEL-5.10-2026-135)	Nessus	Amazon Linux Local Security Checks	2026/10/17	2026/10/22	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
347646	Linux Distros 未修補弱點：CVE-2026-93048	Nessus	Misc.	2026/9/18	2026/11/4	medium

偵測

搜尋 Plugin

high

high

high

high

high

high

medium

medium

high

high

medium