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

  - bpf同期コールバックの参照状態管理を修正現在、verifier はコールバック関数sync および asyncを、1 回実行されるかのように検証しますつまり、関数が一度呼び出されているかのように実行状態を探索します。探索する次の insn が subprog の開始に設定され、ネストされたフレームからの終了が、curframe > 0 および prepare_func_exit を使用して処理されます。async コールバックの場合、ある種のブランチをエミュレートする push_stack のカスタマイズされたバリアントが使用され、async コールバック用のカスタム状態と実行コンテキストが設定されます。このアプローチはシンプルで、コールバックが実際に一度だけ実行される場合は機能しますが、for_each スタイルである現在のすべてのヘルパーにとって安全ではありません。つまり、コールバックを複数回実行します。呼び出し元の取得した参照をリリースするコールバックは、複数回行われる可能性がありますが、現在の検証機能ではこれがフレーム内の 1 つの呼び出しと見なされ、呼び出し元に返されます。したがって、cb eg が callback_ctx を通じてアクセス権を取得したという参照をリリースしていましたスタックで、漏洩した型付きレジスターから cb の内部をレジスターで埋め込まれたと考えられます。同様に、取得呼び出しがコールバック内でペアリングされていないことが判明した場合、呼び出し側はコールバックの参照状態をコピーしてから、新しい ref_obj_ids でレジスターをリリースする必要があります。しかし、コールバックは複数回実行される可能性がありますが、検証機能はコールバックの単一のシンボリック実行のために取得された参照のみを考慮し、これにより漏洩が発生します。注意非同期コールバックの場合は状況が異なります。現在は、それを一度実行するだけの bpf_timer_set_callback がありますが、参照状態が NULL であり、check_reference_leak は BPF_EXIT の前にプログラムを強制的に状態を解放するため、複数の実行の場合でも安全です。状態は、呼び出し元フレームの分析によっても影響を受けません。したがって、async コールバックは安全です。参照状態をアクセス可能にしたいので、ポインターなどが callback_ctx の PTR_TO_STACK を通じてスタックからロードされた場合など、呼び出し元の Reference_state を callback の bpf_func_state へコピーする必要がありますが、参照状態に追加される参照はすべて、BPF_EXIT にヒットする前にリリースされるように強制します。これには、参照状態に新しい callback_ref メンバーを導入して、呼び出し元と呼び出し先の参照を区別する必要があります。そのため、check_reference_leak は、コールバック_fn 内にあり、callback_ref refs をリリースしていないことが判明した場合に、エラーを出力するようになりました。フレーム 0 -> cb1 -> cb2 など、複数のネスト化されたコールバックが存在する可能性があります。
    また、この特定の ref が、このコールバックフレームまたは親に属しているかどうかと、自分自身のもののみを区別する必要があるため、state->frameno を保存しますコールバックに対しては常にゼロではありません。つまり、コールバックは親の Reference_state を読み込むことができますが、それを変更することはできず、呼び出し側が取得したポインターを使用できるようになります。返す前に呼び出し側のreference_state に加えて、BPF_EXIT の前に独自のacquire_refs をリリースすることで変更を取り消すだけで済みますこの時点で呼び出し側とコールバックの状態は一致するため、呼び出し側にコピーして戻す必要はありません。CVE-2022-50650

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

リモートホストにインストールされているカーネルのバージョンは、5.15.75-48.135より前のものです。したがって、ALAS2KERNEL-5.15-2025-090 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

    問題として分類されている脆弱性が Linux カーネルで見つかりました。この問題は、コンポーネント BPF のファイル fs/nilfs2/segment.c の関数 nilfs_attach_log_writer に影響します。操作により、メモリリークが発生します。攻撃がリモートで開始される可能性があります。この問題を修正するパッチを適用することが推奨されます。識別子 VDB-211961 がこの脆弱性に割り当てられました。(CVE-2022-3646)

    5.19.9 までの Linux カーネルの drivers/scsi/stex.c により、stex_queuecommand_lck に PASSTHRU_CMD の場合の memset がないため、ローカルユーザーがカーネルメモリから機密情報を取得する可能性があります。
    (CVE-2022-40768)

    バージョン 5.19.17 および 6.0.2 より前の Linux カーネル NFSD の実装は、バッファオーバーフローに脆弱です。NFSD は、リモートプロシージャコール (RPC) の受信バッファと送信バッファを単一のページ配列に結合することで、各 NFSD スレッドが保持しているページ数を追跡します。クライアントは、ガベージデータがメッセージの最後に追加された RPC メッセージを TCP で送信することで、送信バッファを強制的に縮小できます。ガベージデータのある RPC メッセージは、依然として仕様に従って正しく形成されており、ハンドラーに転送されます。NFSD の脆弱なコードは、サイズが大きすぎるリクエストを想定しておらず、割り当てられたバッファスペースを超えて書き込みます。CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (CVE-2022-43945)

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv2 READDIR での送信バッファオーバーフローに対する保護CVE-2022-50235]

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDサーバー間コピーを行う際のソースサーバーの use-after-free を修正しますCVE-2022-50241

    Linux カーネルで、以下の脆弱性が解決されています。

    sctpsctp_auth_asoc_init_active_key から返されるエラーを処理CVE-2022-50243

    Linux カーネルで、以下の脆弱性が解決されています。

    xen/gntdev認可の漏洩を防止CVE-2022-50257

    Linux カーネルで、以下の脆弱性が解決されています。

    vhost/vsock大きなパケットに対して kvmalloc/kvfree を使用します。CVE-2022-50271

    Linux カーネルで、以下の脆弱性が解決されています。

    mdsnprintf を scnprintf で置換しますCVE-2022-50299

    Linux カーネルで、以下の脆弱性が解決されています。

    nbdシグナルが nbd_start_device_ioctl() を割り込む際のハングアップを修正しますCVE-2022-50314]

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2jbd2_fc_wait_bufs の潜在的な use-after-free を修正しますCVE-2022-50328

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_write_info の null-ptr-deref を修正CVE-2022-50344

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv3 READ の送信バッファオーバーフローに対する保護CVE-2022-50345

    Linux カーネルで、以下の脆弱性が解決されています。

    nfsdエラー処理パスでのメモリリークを修正しますCVE-2022-50348

    Linux カーネルで、以下の脆弱性が解決されています。

    btrfsクォータの有効化とクォータ再スキャンの ioctl の間の競合を修正しますCVE-2022-50379

    Linux カーネルで、以下の脆弱性が解決されています。

    net/ieee802154ゼロサイズの raw_sendmsg() を拒否しますCVE-2022-50397

    Linux カーネルで、以下の脆弱性が解決されています。

    netsock がデッドの場合は sk_stream_wait_memory の sock の sk_wq にアクセスしませんCVE-2022-50409

    Linux カーネルで、以下の脆弱性が解決されています。

    NFSDNFSv2 READ の送信バッファオーバーフローに対する保護CVE-2022-50410

    Linux カーネルで、以下の脆弱性が解決されています。

    scsilibsassmp_execute_task_sg() の use-after-free バグを修正しますCVE-2022-50422

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4DIO 書き込みの後のインラインデータ作成でのクラッシュを回避しますCVE-2022-50435

    Linux カーネルで、以下の脆弱性が解決されています。

    xfrmworkqueue を通じてトランスポートモードパケットを再注入しますCVE-2022-50445

    Linux カーネルで、以下の脆弱性が解決されています。

    xen/gntdevVMA 分割に対応しますCVE-2022-50471

    Linux カーネルで、以下の脆弱性が解決されています。

    drm/mipi-dsiホストを削除する際にデバイスをデタッチしますCVE-2022-50489

    Linux カーネルで、以下の脆弱性が解決されています。

    bpfhtab_lock_bucket() からユーザー空間にエラーが伝播されますCVE-2022-50490]

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_fc_record_regions() での潜在的なメモリリークを修正しますCVE-2022-50512]

    Linux カーネルで、以下の脆弱性が解決されています。

    usbhostxhcixhci_alloc_stream_info() の潜在的なメモリリークを修正しますCVE-2022-50544

    Linux カーネルで、以下の脆弱性が解決されています。

    xfrm解放時に ipcomp_scratches を NULL で更新しますCVE-2022-50569

    Linux カーネルで、以下の脆弱性が解決されています。

    arm64ftracemcount のあるモジュール PLT を修正しますCVE-2022-50579

    Linux カーネルで、以下の脆弱性が解決されています。

    blk-throttle待機時間の計算中のオーバーフローを防止しますCVE-2022-50580

    Linux カーネルで、以下の脆弱性が解決されています。

    ext4ext4_fc_record_modified_inode() での潜在的なメモリリークを修正しますCVE-2022-50622]

    Linux カーネルで、以下の脆弱性が解決されています。

    mmhugetlbhugetlb_handle_userfault の UAF を修正しますCVE-2022-50630

    Linux カーネルで、以下の脆弱性が解決されています。

    io-wqワーカー作成でのメモリリークを修正しますCVE-2022-50639

    Linux カーネルで、以下の脆弱性が解決されています。

    bpf同期コールバック用の参照状態管理を修正しますCVE-2022-50650

    Linux カーネルで、以下の脆弱性が解決されています。

    RDMA/swiwQP 破壊を修正し、すべての参照がドロップされるのを待機します。CVE-2022-50666

    Linux カーネルで、以下の脆弱性が解決されています。

    netrdsrds_tcp_reset_callbacks() から作業をキャンセルする際に sock ロックを保留しませんCVE-2022-50676]

    Linux カーネルで、以下の脆弱性が解決されています。

    net/ieee802154警告しませんゼロサイズの raw_sendmsg()CVE-2022-50706]

    Linux カーネルで、以下の脆弱性が解決されています。

    cryptoakcipher - 秘密鍵設定のデフォルト実装CVE-2022-50731

    Linux カーネルで、以下の脆弱性が解決されています。

    md/raid5raid5_read_one_chunk() の中の不要な bio_put() を削除しますCVE-2022-50752

    Linux カーネルで、以下の脆弱性が解決されています。

    btrfsbtrfs_init_new_buffer で btrfs_clean_tree_block を呼び出す前に、生成を設定しますCVE-2022-50766

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2fc_do_one_pass() にミスリリースバッファヘッドを追加しますCVE-2022-50835]

    Linux カーネルで、以下の脆弱性が解決されています。

    jbd2潜在的なバッファヘッド参照カウントの漏洩を修正しますCVE-2022-50839

    Linux カーネルで、以下の脆弱性が解決されています。

    cifsVALIDATE_NEGOTIATE_INFO メッセージのエラー長を修正CVE-2022-50859

    Linux カーネルで、以下の脆弱性が解決されています。

    drmdrm_copy_field() による NULL ポインターのコピーを試行することを阻止しますCVE-2022-50884]

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
278044	Linux Distros のパッチ未適用の脆弱性: CVE-2022-50650	Nessus	Misc.	2025/12/10	2026/9/30	high
266163	Amazon Linux 2kernel、 --advisory ALAS2KERNEL-5。15-2025-090 ALASKERNEL-5.15-2025-090	Nessus	Amazon Linux Local Security Checks	2025/9/30	2026/2/9	high
352031	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-abi-stablelists/kernel-core/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical

検出

プラグインの検索

high

high

critical