Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - RDMA/siw:siw_accept() の use-after-free を修正しますsiw_accept() は、ユーザー空間が指定した QP を検索します。その QP がすでに RTS にある場合、この関数は、着信 CEP をそれに関連付ける前にエラークリーンアップにジャンプします。クリーンアップは、qp->cep が NULL 以外であるかどうかをテストし、現在の呼び出しが関連付けをインストールしたと想定します。ただし、qp->cep は既存の接続の CEP を指し示すことが可能です。その後、クリーンアップは、qp->cep ではなく、着信 cep からの参照をドロップします。受信エンドポイントが残りの参照を失うと、後続のcep->qpストアの前にエンドポイントが解放され、メモリ解放後使用(Use After Free)が引き起こされます。また、既存の QP の関連付けもクリアされます。
    qp->cep が着信 CEP の場合にのみ関連付け参照をリリースします。これにより、既存の関連付けが維持され、解放されたエンドポイントへのアクセスが不要になります。(CVE-2026-90292)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

AlmaLinux 9.6 ホストには、TuxCare ALMALINUX9.6:CLSA-2026:1792445930アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). (CVE-2024-57793)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: af_alg - zero initialize memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures. A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data. (CVE-2025-71113)

  - Linux カーネルでは、以下の脆弱性が解決されています: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example (CVE-2026-31630)

  - Linux カーネルでは、以下の脆弱性が解決されています: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - Linux カーネルでは、以下の脆弱性が解決されています: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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 はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

Rocky Linuxの 9.6 ホストには、TuxCare ALMALINUX9.6:CLSA-2026:1792445930アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE(). (CVE-2024-57793)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: af_alg - zero initialize memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures. A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data. (CVE-2025-71113)

  - Linux カーネルでは、以下の脆弱性が解決されています: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example (CVE-2026-31630)

  - Linux カーネルでは、以下の脆弱性が解決されています: netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous set checks on start elements for this reason. However, it is possible to add intervals that overlap to this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - Linux カーネルでは、以下の脆弱性が解決されています: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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 はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ID	名前	製品	ファミリー	公開日	更新日	深刻度
347594	Linux Distros のパッチ未適用の脆弱性: CVE-2026-90292	Nessus	Misc.	2026/9/18	2026/11/6	high
369490	AlmaLinux 9.6 [TuxCare] セキュリティ更新プログラム:kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Alma Linux Local Security Checks	2026/10/21	2026/10/21	high
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
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/27	medium
369491	Rocky Linux 9.6 [TuxCare] セキュリティ更新プログラム:kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Rocky Linux Local Security Checks	2026/10/21	2026/10/21	high
366742	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:4706-1)	Nessus	SuSE Local Security Checks	2026/10/17	2026/10/17	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

検出

プラグインの検索

high

high

high

high

medium

high

high

high