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

  - Linux カーネルでは、以下の脆弱性が解決されています: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. (CVE-2022-49357)

  - Linux カーネルでは、以下の脆弱性が解決されています: scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0:
    slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete:
    task(0000000022d52d93) ignored [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete:
    task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate:
    00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp : ffff00001d623bc0 [7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26:
    ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23:
    ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16:
    0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13:
    ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 :
    ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 :
    ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas] [ 7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception To fix the issue, grab sas_dev lock when traversing the members of sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid concurrency of adding and deleting member. When ---truncated--- (CVE-2023-53627)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048
    __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline]
    __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
    __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df (bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()) fixed one NULL pointer similarly due to no protection of saved_data_ready.
    Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses write_lock_bh(&sk->sk_callback_lock);. To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. (CVE-2024-36938)

  - Linux カーネルでは、以下の脆弱性が解決されています: virtiofs: use pages instead of pointer for kernel direct IO When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ......
    Call Trace: <TASK> ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160
    __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230
    __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first. 2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter(). 3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever. A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel. So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data. After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations. It may seem necessary to introduce another fie ---truncated--- (CVE-2024-53219)

  - Linux カーネルでは、以下の脆弱性が解決されています: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.
    Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though. (CVE-2025-21846)

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

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

  - rxrpc:データ競合の警告と潜在的なロード/ストアのティアリングを修正します 次を修正します:バグ:KCSAN:rxrpc_peer_keepalive_worker/rxrpc_send_data_packet のデータ競合は、次の >last_tx_at への読み取りと書き込みの問題を報告しています:conn->peer->last_tx_at = ktime_get_seconds();および: keepalive_at = ピア>last_tx_at + RXRPC_KEEPALIVE_TIME;キープアライブパケットの送信がまだ正当化されるかどうかを判断する目的で、読み取りが最終送信のおおよその時間のみを必要とするため、これらの値へのロックレスアクセスは、実際には問題になりません。また、->last_tx_at は 64 ビットの値であるため、32 ビットの arch でティアリングが発生する可能性があります。->last_tx_at の符号なし整数に切り替え、time64_tの LSW のみを格納することで、これらの両方を修正します。その後、最後の送信から68年以内であれば、必要に応じて再構築することができます。(CVE-2026-23118)

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

リモートの Oracle Linux 10 / 9 ホストに、ELSA-2026-50160 アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

    - mm/hugetlb: hugetlb_pmd_shared() を修正します (David Hildenbrand 氏) [Orabug: 38931087] {CVE-2026-23100}
    - platform/x86: classmate-laptop: NULL ポインターチェックの不足を追加します (Rafael J. Wysocki 氏) [Orabug: 39044501] {CVE-2026-23237}
    - scsi: qla2xxx: bsg_done() が二重解放を引き起こす問題を修正します (Anil Gurumurthy 氏) [Orabug: 39044457] {CVE-2025-71238}
    - wifi: rtl8xxxu: rtl8xxxu_sta_add() におけるスラブ領域外アクセスを修正します (Ali Tariq 氏) [Orabug: 38997990] {CVE-2025-71234}
    - xfs: xchk_btree_check_block_owner() におけるメモリ解放後使用 (Use-After-Free) を修正します (Darrick J. Wong 氏) [Orabug: 38998028] {CVE-2026-23223}
    - scsi: qla2xxx: エラー パスで sp を解放し、システム クラッシュを修正します (Anil Gurumurthy 氏) [Orabug: 38997979] {CVE-2025-71232}
    - scsi: qla2xxx: ファブリックスキャンの実行中はモジュールのアンロードを遅延します (Anil Gurumurthy 氏) [Orabug: 38997992] {CVE-2025-71235}
    - scsi: qla2xxx: 関連するメモリを解放する前に sp を検証します (Anil Gurumurthy 氏) [Orabug: 38997998] {CVE-2025-71236}
    - wifi: rtw88: rtw_core_enable_beacon() におけるアラインメントエラーを修正します (Bitterblue Smith 氏) [Orabug: 38997972] {CVE-2025-71229}
    - crypto: virtio - virtqueue 通知に対するスピンロック保護を追加します (Bibo Mao 氏) [Orabug: 38998052] {CVE-2026-23229}
    - crypto: iaa - find_empty_iaa_compression_mode() における範囲外インデックスを修正します (Thorsten Blum 氏) [Orabug:
    38997976] {CVE-2025-71231}
    - smb: client: 共有バイトの RMW 競合を回避するため、cached_fid のビットフィールドを分割します (Henrique Carvalho 氏) [Orabug:
    38998059] {CVE-2026-23230}
    - spi: tegra210-quad: tegra_qspi_combined_seq_xfer() における curr_xfer を保護します (Breno Leitao 氏) [Orabug: 38970593] {CVE-2026-23202}
    - ASoC: amd: acp3x pdm DMA ops におけるメモリリークを修正します (Chris Bainbridge 氏) [Orabug: 38970441] {CVE-2026-23190}
    - ipv6: RTF_ADDRCONF をクリアする際の ECMP シスリング数の不一致を修正します (Shigeru Yoshida 氏) [Orabug: 38970598] {CVE-2026-23200}
    - netfilter: nf_tables: nft_map_catchall_activate() における genmask の逆チェックを修正します (Andrew Fasano 氏) [Orabug:
    38970170] {CVE-2026-23111}
    - net: usb: r8152: 再開時のリセットにおけるデッドロックを修正します (Sergey Senozhatsky 氏) [Orabug: 38970438] {CVE-2026-23188}
    - macvlan: macvlan_common_newlink() におけるエラー回復処理を修正します (Eric Dumazet 氏) [Orabug: 38970508] {CVE-2026-23209}
    - net/sched: cls_u32: skb_header_pointer_careful() を使用します (Eric Dumazet 氏) [Orabug: 38970487] {CVE-2026-23204}
    - smb/client: smb2_open_file() におけるメモリリークを修正します (Chenxiaosong 氏) [Orabug: 38970578] {CVE-2026-23205}
    - btrfs: ファイルシステムが完全に読み取り専用の場合、新規トランザクションを拒否します (Qu Wenruo 氏) [Orabug: 38985156] {CVE-2026-23214}
    - scsi: target: iscsi: iscsit_dec_conn_usage_count() におけるメモリ解放後使用 (Use-After-Free) を修正します (Maurizio Lombardi 氏) [Orabug:
    38985169] {CVE-2026-23216}
    - scsi: target: iscsi: iscsit_dec_session_usage_count() におけるメモリ解放後使用 (Use-After-Free) を修正します (Maurizio Lombardi 氏) [Orabug:
    38970453] {CVE-2026-23193}
    - nvmet-tcp: nvmet_tcp_listen_data_ready() におけるハングを修正します (Hannes Reinecke 氏) [Orabug: 38970416] {CVE-2026-23179}
    - drm/amd/pm: SMU モード 1 リセット中は MMIO アクセスを無効にします (Perry Yuan 氏) [Orabug: 38985149] {CVE-2026-23213}
    - HID: i2c-hid: i2c_hid_get_report() における潜在的なバッファオーバーフローを修正します (Kwok Kin Ming 氏) [Orabug: 38970413] {CVE-2026-23178}
    - md: sysfs を通じて raid_disks を更新する間、配列を一時停止します (Danny Shih 氏) [Orabug: 38985108] {CVE-2025-71225}
    - wifi: wlcore: skb_push の前に skb ヘッドルームを確保します (Peter Astrand 氏) [Orabug: 38970152] {CVE-2025-71222}
    - wifi: mac80211: ocb: インターフェースが参加していない場合は rx_no_sta をスキップします (Moon Hee Lee 氏) [Orabug: 38970163] {CVE-2025-71224}
    - procfs: VMA ロック保持中のビルド ID の取得を回避します (Andrii Nakryiko 氏) [Orabug: 38970476] {CVE-2026-23199}
    - mm, shmem: truncate の競合による無限ループを防ぎます (Kairui Song 氏) [Orabug: 38970409] {CVE-2026-23177}
    - ceph: parse_longname() における kfree() 用の不正なポインタによる Oops を修正します (Daniel Vogelbacher 氏) [Orabug:
    38970590] {CVE-2026-23201}
    - ceph: ceph_mds_auth_match() における NULL ポインターデリファレンスを修正します (Viacheslav Dubeyko 氏) [Orabug: 38970595] {CVE-2026-23189}
    - mm/slab: memcg_alloc_abort_single 用の alloc_tagging_slab_free_hook を追加します (Hao Ge 氏) [Orabug: 38985192] {CVE-2026-23219}
    - ALSA: aloop: PCM トリガーでの競合アクセスを修正します (Takashi Iwai 氏) [Orabug: 38970445] {CVE-2026-23191}
    - x86/vmware: ハイパーコールの上書きを修正します (Josh Poimboeuf 氏) [Orabug: 38985163] {CVE-2026-23215}
    - nvmet-tcp: nvmet_tcp_build_pdu_iovec() に境界チェックを追加します (Yunje Shin 氏) [Orabug: 38970176] {CVE-2026-23112}
    - perf: sched: 新しい is_user_task() ヘルパーでの perf クラッシュを修正します (Steven Rostedt 氏) [Orabug: 38970581] {CVE-2026-23159}
    - wifi: ath11k: モニターモードにおいて ath11k_hal_srng_* に srng->lock を追加します (Kang Yang 氏) [Orabug: 37844126] {CVE-2024-58096}
    - drm/amdgpu: amdgpu_gmc_filter_faults_remove() における NULL ポインターデリファレンスを修正します (Jon Doron 氏) [Orabug:
    38970348] {CVE-2026-23163}
    - net: forwarding fraglist GRO のセグメンテーションを修正します (Jibin Zhang 氏) [Orabug: 38970318] {CVE-2026-23154}
    - mm/shmem, swap: truncate と swap エントリーの分割の競合を修正します (Kairui Song 氏) [Orabug: 38970345] {CVE-2026-23161}
    - flex_proportions: fprop_new_period() hardirq を安全にします (Jan Kara 氏) [Orabug: 38970373] {CVE-2026-23168}
    - nvmet: nvmet_bio_done() における競合が NULL ポインターデリファレンスを引き起こす問題を修正します (Ming Lei 氏) [Orabug: 38970608] {CVE-2026-23148}
    - efivarfs: efivar_entry_get() におけるエラー伝播を修正します (Kohei Enju 氏) [Orabug: 38970325] {CVE-2026-23156}
    - net/mlx5e: TC、既存のピアに対してのみフローを削除します (Mark Bloch 氏) [Orabug: 38970397] {CVE-2026-23173}
    - ice: ice_vsi_set_napi_queues() における NULL ポインターデリファレンスを修正します (Aaron Ma 氏) [Orabug: 38970364] {CVE-2026-23166}
    - rocker: rocker_world_port_post_fini() におけるメモリリークを修正します (Kery Qi 氏) [Orabug: 38970351] {CVE-2026-23164}
    - bonding: slave->last_rx 周辺のデータ競合を注釈します (Eric Dumazet 氏) [Orabug: 38985142] {CVE-2026-23212}
    - Bluetooth: MGMT: set_ssp_complete() におけるメモリリークを修正します (Jianpeng Chang 氏) [Orabug: 38970587] {CVE-2026-23151}
    - Bluetooth: hci_uart: hci_uart_write_work() における NULL ポインターデリファレンスを修正します (Jia-Hong Su 氏) [Orabug: 38970604] {CVE-2026-23146}
    - wifi: ath11k: モニターの宛先リングの回収中に発生する RCU ストールを修正します (P Praneesh 氏) [Orabug: 37844129] {CVE-2024-58097}
    - btrfs: btrfs_clear_space_info_full() におけるビットフィールドの競合書き込みを修正します (Boris Burkov 氏) [Orabug: 38798802] {CVE-2025-68358}
    - sched_ext: deferred_irq_workfn() における潜在的なデッドロックを修正します (Zqiang 氏) [Orabug: 38792605] {CVE-2025-68333}
    - exfat: exfat_find() における refcount 漏洩を修正します (Shuhao Fu 氏) [Orabug: 38798780] {CVE-2025-68351}
    - bpf: BPF テストインフラが無効な GSO タイプをスタックに出力しないようにします (Daniel Borkmann 氏) [Orabug: 38798881] {CVE-2025-68725}
    - migrate: hugetlb ファイルフォリオに対するロック順序を修正します (Matthew Wilcox 氏) [Orabug: 38931066] {CVE-2026-23097}
    - can: usb_8dev: usb_8dev_read_bulk_callback(): URB のメモリリークを修正します (Marc Kleine-Budde 氏) [Orabug: 38931120] {CVE-2026-23108}
    - can: kvaser_usb: kvaser_usb_read_bulk_callback(): URB のメモリリークを修正します (Marc Kleine-Budde 氏) [Orabug:
    38930881] {CVE-2026-23061}
    - can: ems_usb: ems_usb_read_bulk_callback(): URB のメモリリークを修正します (Marc Kleine-Budde 氏) [Orabug: 38930859] {CVE-2026-23058}
    - irqchip/gic-v3-its: メモリアドレスの切り捨てを回避します (Arnd Bergmann 氏) [Orabug: 38931001] {CVE-2026-23085}
    - intel_th: output open() におけるデバイスリークを修正します (Johan Hovold 氏) [Orabug: 38931040] {CVE-2026-23091}
    - tracing: synthetic stacktrace フィールドの使用時のクラッシュを修正します (Steven Rostedt 氏) [Orabug: 38931024] {CVE-2026-23088}
    - arm64: swsusp_arch_resume() に __nocfi を設定します (Zhaoyang Huang 氏) [Orabug: 38970241] {CVE-2026-23128}
    - arm64/fpsimd: signal: ZA の復元時に SSVE ストレージを割り当てます (Mark Rutland 氏) [Orabug: 38931118] {CVE-2026-23107}
    - wifi: rsi: vif ドライバデータサイズ未設定によるメモリ破損を修正します (Marek Vasut 氏) [Orabug: 38930939] {CVE-2026-23073}
    - wifi: ath10k: dma_free_coherent() のポインタを修正します (Thomas Fourier 氏) [Orabug: 38970253] {CVE-2026-23133}
    - ALSA: usb-audio: snd_usb_mixer_free() におけるメモリ解放後使用 (Use-After-Free) を修正します (Berk Cem Goksel 氏) [Orabug: 38931029] {CVE-2026-23089}
    - ALSA: scarlett2: config 取得時のバッファオーバーフローを修正します (Samasth Norway Ananda 氏) [Orabug: 38930973] {CVE-2026-23078}
    - ALSA: ctxfi: オーディオミキサー処理における潜在的な OOB アクセスを修正します (Takashi Iwai 氏) [Orabug: 38930966] {CVE-2026-23076}
    - leds: led-class: LED が完全に準備できている場合にのみ leds_list に追加します (Hans de Goede 氏) [Orabug: 38931091] {CVE-2026-23101}
    - dpll: 重複登録を防ぎます (Ivan Vecera 氏) [Orabug: 38970244] {CVE-2026-23129}
    - vsock/virtio: TX クレジットをローカルバッファサイズに制限します (Melbin K Mathew 氏) [Orabug: 38931008] {CVE-2026-23086}
    - vsock/virtio: virtio_transport_get_credit() における潜在的なアンダーフローを修正します (Melbin K Mathew 氏) [Orabug:
    38930919] {CVE-2026-23069}
    - bonding: __skb_flow_dissect() に net ポインタを渡します (Eric Dumazet 氏) [Orabug: 38970199] {CVE-2026-23119}
    - be2net: be_cmd_get_mac_from_list() における NULL ポインターデリファレンスを修正します (Andrey Vatoropin 氏) [Orabug: 38930992] {CVE-2026-23084}
    - ipv6: ndisc_router_discovery() におけるデータ競合を注釈します (Eric Dumazet 氏) [Orabug: 38970222] {CVE-2026-23124}
    - netdevsim: bpf_bound_progs リストの操作に関連する競合問題を修正します (Yun Lu 氏) [Orabug: 38970233] {CVE-2026-23126}
    - scsi: qla2xxx: メンバーオーバーフローを防ぐためにペイロードサイズをサニタイズします (Jiasheng Jiang 氏) [Orabug: 38930867] {CVE-2026-23059}
    - scsi: core: 最終完了が競合した場合にエラーハンドラーを起動します (David Jeffery 氏) [Orabug: 38931132] {CVE-2026-23110}
    - regmap: hwspinlock irqsave ルーチンでの競合状態を修正します (Cheng-Yu Lee 氏) [Orabug: 38930930] {CVE-2026-23071}
    - interconnect: debugfs: src_node および dst_node を空文字列で初期化します (Georgi Djakov 氏) [Orabug:
    38970218] {CVE-2026-23123}
    - io_uring/io-wq: work 実行ループ内で IO_WQ_BIT_EXIT をチェックします (Jens Axboe 氏) [Orabug: 38970181] {CVE-2026-23113}
    - platform/x86: hp-bioscfg: GET_INSTANCE_ID マクロでのカーネルパニックを修正します (Mario Limonciello 氏) [Orabug:
    38930890] {CVE-2026-23062}
    - platform/x86: hp-bioscfg: 空の属性名に対する kobject 警告を修正します (Mario Limonciello 氏) [Orabug:
    38970247] {CVE-2026-23131}
    - scsi: xen: scsiback: scsiback_remove() における潜在的なメモリリークを修正します (Abdun Nihaal 氏) [Orabug: 38931014] {CVE-2026-23087}
    - w1: therm: alarms_store における off-by-one のバッファオーバーフローを修正します (Thorsten Blum 氏) [Orabug: 38930796] {CVE-2025-71197}
    - crypto: authencesn - ESP/ESN 仕様に合わせて、短すぎる AAD (assoclen<8) を拒否します (Taeyang Lee 氏) [Orabug:
    38930874] {CVE-2026-23060}
    - net/sched: qfq: qfq_rm_from_ag でクラスがアクティブかどうかを cl_is_active で判定します (Jamal Hadi Salim 氏) [Orabug: 38931110] {CVE-2026-23105}
    - net/sched: teql をルート qdisc としてのみ使用できるように強制します (Jamal Hadi Salim 氏) [Orabug: 38930948] {CVE-2026-23074}
    - ipvlan: addrs_lock をポートごとに分割します (Dmitry Skorodumov 氏) [Orabug: 38931102] {CVE-2026-23103}
    - l2tp: l2tp_tunnel_del_work() における 1 つのデータ競合を回避します (Eric Dumazet 氏) [Orabug: 38970202] {CVE-2026-23120}
    - gue: 内部 IP プロトコル 0 での skb メモリリークを修正します (Kuniyuki Iwashima 氏) [Orabug: 38931057] {CVE-2026-23095}
    - sctp: SCTP_CMD_PEER_INIT の直後に SCTP_CMD_ASSOC_SHKEY を移動します (Xin Long 氏) [Orabug: 38970225] {CVE-2026-23125}
    - can: gs_usb: gs_usb_receive_bulk_callback(): usb_submit_urb() エラー時に URL のアンカーを解除します (Marc Kleine-Budde 氏) [Orabug: 38931184] {CVE-2026-23082}
    - l2tp: l2tp_udp_encap_recv() のメモリリークを修正します。(Kuniyuki Iwashima 氏) [Orabug: 38930935] {CVE-2026-23072}
    - bonding: BOND_MODE_8023AD をイーサネット デバイスに限定します (Eric Dumazet 氏) [Orabug: 38931079] {CVE-2026-23099}
    - vsock/virtio: リニア skb のみを結合します (Michal Luczaj 氏) [Orabug: 38930857] {CVE-2026-23057}

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

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

リモートの Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS ホストには、USN-8669-1 のアドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

    Linux カーネルで、いくつかのセキュリティ上の問題が検出されました。攻撃者がこれらを使用して、システムを侵害する可能性があります。この更新では、以下のサブシステムの欠陥を修正しました。

    - フーオーバー UDP (FOU);

    - ARM64 アーキテクチャ

    - x86 アーキテクチャ

    - ブロック層のサブシステム

    - ドライバーコア

    - Null ブロックデバイスドライバー

    - Bluetooth ドライバー

    - カウンターインターフェイスドライバー

    - DMA エンジンサブシステム

    - DPLL サブシステム

    - GPIO サブシステム

    - GPU ドライバー

    - I2C サブシステム

    - IIO ADC ドライバー

    - IIO サブシステム

    - InfiniBand ドライバー

    - On-Chip Interconnect 管理フレームワーク

    - IOMMU サブシステム

    - IRQ チップドライバー

    - モジュラー ISDN ドライバー

    - LED サブシステム

    - 複数のデバイスのドライバー

    - メディアドライバー

    - UACC アクセラレーターフレームワーク

    - MMC サブシステム

    - イーサネット結合ドライバー

    - ネットワークドライバー

    - Mellanox network ドライバー

    - Texas Instruments ネットワークドライバー

    - NVME ドライバー

    - デバイスツリーおよびオープンファームウェアドライバー

    - PHY ドライバー

    - x86 プラットフォームドライバー

    - i.MX PM ドメイン

    - SCSI サブシステム

    - SLIMbus ドライバー

    - SPI サブシステム

    - TTY ドライバー

    - USB ホストコントローラードライバー

    - W1 Dallas の 1-wire バスドライバー

    - Xen ハイパーバイザードライバー

    - BTRFS ファイルシステム

    - EFI 変数ファイルシステム

    - ファイルシステムインフラ

    - Ext4 ファイルシステム

    - FUSE (ユーザー空間でのファイルシステム)

    - ネットワークファイルシステムライブラリ

    - ネットワークファイルシステム (NFS) クライアント

    - ネットワークファイルシステム (NFS) サーバーデーモン

    - SMB ネットワークファイルシステム

    - メモリ管理

    - メモリ管理

    - スケジューラインフラストラクチャ

    - トレースインフラ

    - IPv4 ネットワーキング

    - Netfilter

    - NFC サブシステム

    - ネットワークトラフィックコントロール

    - TCP ネットワークプロトコル。

    - io_uring サブシステム

    - Perf イベント

    - プリミティブのロック

    - ハイバネーションコントロール

    - Timer サブシステム

    - BPF サブシステム

    - フローティングプロポーションライブラリ

    - Bluetooth サブシステム

    - CAN ネットワークレイヤー

    - Ceph Core ライブラリ

    - Networking コア

    - IPv6 ネットワーキング

    - L2TP プロトコル

    - MAC80211 サブシステム

    - マルチパス TCP

    - NET/ROM レイヤー

    - RxRPC セッションソケット

    - SCTP プロトコル

    - SMC ソケット

    - VMware vSockets ドライバー

    - ワイヤレスネットワーキング

    - ALSA AC97 ドライバー

    - Creative Sound Blaster X-Fi ドライバー

    - Texas InstrumentS Audio (ASoC/HDA) ドライバー。

    - USBサウンドデバイス;(CVE-2025-71158、 CVE-2025-71160、 CVE-2025-71161、 CVE-2025-71162、 CVE-2025-71163、 CVE-2025-71180、 CVE-2025-71182、 CVE-2025-71183、 CVE-2025-71184、 CVE-2025-71185、 CVE-2025-71186、 CVE-2025-71187、 CVE-2025-71188、 CVE-2025-71189、 CVE-2025-71190、 CVE-2025-71191、 CVE-2025-71192、 CVE-2025-71193、 CVE-2025-71194、 CVE-2025-71195、 CVE-2025-71196、 CVE-2025-71197、 CVE-2025-71198、 CVE-2025-71199、 CVE-2025-71200、 CVE-2025-71201、 CVE-2026-22976、 CVE-2026-22977、 CVE-2026-22978、 CVE-2026-22979、 CVE-2026-22980、 CVE-2026-22981CVE-2026-22982、 CVE-2026-22985、 CVE-2026-22986、 CVE-2026-22987、 CVE-2026-22989、 CVE-2026-22990、 CVE-2026-22991、 CVE-2026-22992、 CVE-2026-22993、 CVE-2026-22994、 CVE-2026-22996、 CVE-2026-22997、 CVE-2026-22998、 CVE-2026-22999、 CVE-2026-23000、 CVE-2026-23001、 CVE-2026-23002、 CVE-2026-23003、 CVE-2026-23004、 CVE-2026-23005、 CVE-2026-23006、 CVE-2026-23007、 CVE-2026-23008、 CVE-2026-23009、 CVE-2026-23010、 CVE-2026-23011、 CVE-2026-23012、 CVE-2026-23013、 CVE-2026-23014、 CVE-2026-23015、 CVE-2026-23017、 CVE-2026-23018、 CVE-2026-23019、 CVE-2026-23020、 CVE-2026-23021、 CVE-2026-23022、 CVE-2026-23023、 CVE-2026-23024、 CVE-2026-23025、 CVE-2026-23026、 CVE-2026-23030、 CVE-2026-23031、 CVE-2026-23032、 CVE-2026-23033、 CVE-2026-23034、 CVE-2026-23035、 CVE-2026-23036、 CVE-2026-23037、 CVE-2026-23038、 CVE-2026-23042、 CVE-2026-23044、 CVE-2026-23045、 CVE-2026-23046、 CVE-2026-23047、 CVE-2026-23049、 CVE-2026-23050、 CVE-2026-23051、 CVE-2026-23052、 CVE-2026-23053、 CVE-2026-23054、 CVE-2026-23055CVE-2026-23056、 CVE-2026-23057、 CVE-2026-23058、 CVE-2026-23059、 CVE-2026-23061、 CVE-2026-23062、 CVE-2026-23063、 CVE-2026-23064、 CVE-2026-23065、 CVE-2026-23066、 CVE-2026-23067、 CVE-2026-23068、 CVE-2026-23069、 CVE-2026-23070、 CVE-2026-23071、 CVE-2026-23072、 CVE-2026-23073、 CVE-2026-23075、 CVE-2026-23076、 CVE-2026-23077、 CVE-2026-23078、 CVE-2026-23079、 CVE-2026-23080、 CVE-2026-23081、 CVE-2026-23083、 CVE-2026-23084、 CVE-2026-23085、 CVE-2026-23086、 CVE-2026-23087、 CVE-2026-23088、 CVE-2026-23089、 CVE-2026-23090、 CVE-2026-23092、 CVE-2026-23093、 CVE-2026-23094、 CVE-2026-23095、 CVE-2026-23096、 CVE-2026-23097、 CVE-2026-23098、 CVE-2026-23099、 CVE-2026-23100、 CVE-2026-23101、 CVE-2026-23102、 CVE-2026-23103、 CVE-2026-23104、 CVE-2026-23105、 CVE-2026-23106、 CVE-2026-23107、 CVE-2026-23108、 CVE-2026-23109、 CVE-2026-23110、 CVE-2026-23113、 CVE-2026-23114、 CVE-2026-23115、 CVE-2026-23116、 CVE-2026-23118、 CVE-2026-23119CVE-2026-23120、 CVE-2026-23121、 CVE-2026-23122、 CVE-2026-23123、 CVE-2026-23124、 CVE-2026-23125、 CVE-2026-23126、 CVE-2026-23128、 CVE-2026-23129、 CVE-2026-23130、 CVE-2026-23131、 CVE-2026-23133、 CVE-2026-23135、 CVE-2026-23136、 CVE-2026-23137、 CVE-2026-23138、 CVE-2026-23139、 CVE-2026-23140、 CVE-2026-23141、 CVE-2026-23142、 CVE-2026-23143、 CVE-2026-23144、 CVE-2026-23145、 CVE-2026-23146、 CVE-2026-23147、 CVE-2026-23148、 CVE-2026-23150、 CVE-2026-23151、 CVE-2026-23152、 CVE-2026-23154、 CVE-2026-23156、 CVE-2026-23157、 CVE-2026-23158、 CVE-2026-23159、 CVE-2026-23160、 CVE-2026-23161、 CVE-2026-23162、 CVE-2026-23163、 CVE-2026-23164、 CVE-2026-23165、 CVE-2026-23166、 CVE-2026-23167、 CVE-2026-23168、 CVE-2026-23169、 CVE-2026-23170、 CVE-2026-23171、 CVE-2026-23172、 CVE-2026-23173、 CVE-2026-23212、 CVE-2026-31405、 CVE-2026-31414、 CVE-2026-31444、 CVE-2026-31501、 CVE-2026-31589、 CVE-2026-31633、 CVE-2026-31636、 CVE-2026-31705、 CVE-2026-43198、 CVE-2026-43379、 CVE-2026-43465、 CVE-2026-43499、 CVE-2026-46113、 CVE-2026-46137、 CVE-2026-46242、 CVE-2026-46290、 CVE-2026-46317、 CVE-2026-46331、 CVE-2026-52924、 CVE-2026-52989、 CVE-2026-53086、 CVE-2026-53131、 CVE-2026-53176、 CVE-2026-53212、 CVE-2026-53225、 CVE-2026-53228、 CVE-2026-53277、 CVE-2026-53359)

Tenable は、前述の説明ブロックを Ubuntu セキュリティアドバイザリからすでに直接抽出しています。

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

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

  - Linux カーネルでは、以下の脆弱性が解決されています: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. (CVE-2022-49357)

  - Linux カーネルでは、以下の脆弱性が解決されています: scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0:
    slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete:
    task(0000000022d52d93) ignored [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete:
    task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate:
    00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp : ffff00001d623bc0 [7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26:
    ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23:
    ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16:
    0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13:
    ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 :
    ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 :
    ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas] [ 7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception To fix the issue, grab sas_dev lock when traversing the members of sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid concurrency of adding and deleting member. When ---truncated--- (CVE-2023-53627)

  - Linux カーネルでは、以下の脆弱性が解決されています: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048
    __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline]
    __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
    __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df (bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()) fixed one NULL pointer similarly due to no protection of saved_data_ready.
    Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses write_lock_bh(&sk->sk_callback_lock);. To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. (CVE-2024-36938)

  - Linux カーネルでは、以下の脆弱性が解決されています: virtiofs: use pages instead of pointer for kernel direct IO When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ......
    Call Trace: <TASK> ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160
    __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230
    __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first. 2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter(). 3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever. A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel. So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data. After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations. It may seem necessary to introduce another fie ---truncated--- (CVE-2024-53219)

  - Linux カーネルでは、以下の脆弱性が解決されています: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.
    Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though. (CVE-2025-21846)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
351765	Rocky Linux 9.6 【TuxCare】セキュリティ更新プログラム:kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1782382498)	Nessus	Rocky Linux Local Security Checks	2026/9/30	2026/10/19	medium
340680	Ubuntu 24.04 LTS/Pro Realtime 24.04 LTS:Linuxカーネル(Raspberry Pi)の脆弱性(USN-8665-1)	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/8/27	high
299077	Linux Distros のパッチ未適用の脆弱性: CVE-2026-23118	Nessus	Misc.	2026/2/14	2026/11/6	medium
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
303468	Oracle Linux 10 / 9 : Unbreakable Enterprise カーネル (ELSA-2026-50160)	Nessus	Oracle Linux Local Security Checks	2026/3/24	2026/3/24	critical
340678	Ubuntu 24.04 LTS/Pro Realtime 24.04 LTS:Linuxカーネル(NVIDIA)の脆弱性(USN-8669-1)	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/9/23	high
351608	AlmaLinux 9.6 [TuxCare] セキュリティ更新プログラム:kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etcの複数の脆弱性(ALMALINUX9.6:CLSA-2026:1782382498)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	medium

検出

プラグインの検索

medium

high

medium

critical

critical

high

medium