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

  - blk-mqnr_hw_queues を縮小する際のタグ漏洩を修正します。nr_hw_queues を縮小する際に set->tags[] を realloc する必要はありませんが、解放する必要があります。これらのタグは漏洩されます。複製方法1. mount -t configfs configfs /mnt 2. modprobe null_blk nr_devices=0 submit_queues=8 3. mkdir /mnt/nullb/nullb04. echo 1 > /mnt/nullb/nullb0/power 5. echo 4 > /mnt/nullb/nullb0/submit_queues 6. rmdir /mnt/nullb/nullb0 ステップ 4 で、 は 9 つのタグを割り当てます8 つの送信キューと 1 つのポーリングキュー、そしてステップ 5 で、new_nr_hw_queues = 5 になります4 つの送信キューと 1 つのポーリングキュー)。最後のステップ6では、これらの5つのタグのみが解放され、他の4つのタグが漏えいします。
    (CVE-2023-54227)

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

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

  - KVM の AMD ネスト化仮想化 (SVM) に欠陥が見つかりました。悪意のある L1 ゲストが意図的に協調的ネスト化ゲスト (L2) のシャットダウンの傍受に失敗し、ホスト (L0) でページ障害やカーネルパニックを引き起こす可能性があります。(CVE-2022-3344)

  - Linux カーネルでは、以下の脆弱性が解決されています: usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - Linux カーネルでは、以下の脆弱性が解決されています: crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07 \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). (CVE-2022-50650)

  - Linux カーネルでは、以下の脆弱性が解決されています: net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. (CVE-2022-50663)

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	名前	製品	ファミリー	公開日	更新日	深刻度
296680	SUSE SLES15 /openSUSE 15:Linux カーネルのセキュリティ更新(SUSE-SU-2026:0293-1)	Nessus	SuSE Local Security Checks	2026/1/27	2026/9/29	high
296676	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2026:0281-1)	Nessus	SuSE Local Security Checks	2026/1/27	2026/6/26	high
280700	Linux Distros のパッチ未適用の脆弱性: CVE-2023-54227	Nessus	Misc.	2025/12/30	2026/10/17	high
296481	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	2026/1/24	2026/1/24	high
352031	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etc複数の脆弱性(ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical
297194	SUSE SLED15 / SLES15: Linux カーネルのセキュリティ更新 (SUSE-SU-2026:0315-1)	Nessus	SuSE Local Security Checks	2026/1/30	2026/9/29	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

critical

high

high