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;對這些值的無鎖定存取實際上不是問題，因為讀取只需要上次傳輸的大致時間，即可決定是否保證傳輸 keepalive 封包。此外，由於 ->last_tx_at 是 64 位元值，因此 32 位元 arch 上可能會發生撕裂。透過切換到 ->last_tx_at 的未簽名 int 並僅儲存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 中的 slab 超出邊界 (Ali Tariq) [Orabug: 38997990] {CVE-2025-71234}
    - xfs：修正 xchk_btree_check_block_owner 中的 UAF (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：用戶端：分割 cached_fid 位元欄位以避免共用位元組 RMW 爭用 (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：如果 fs 為完全唯讀，則拒絕新交易 (Qu Wenruo) [Orabug: 38985156] {CVE-2026-23214}
    - scsi：目標：iscsi：修正 iscsit_dec_conn_usage_count() 中的釋放後使用 (Maurizio Lombardi) [Orabug:
    38985169] {CVE-2026-23216}
    - scsi：目標：iscsi：修正 iscsit_dec_session_usage_count() 中的釋放後使用 (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：防止截斷爭用時發生無限迴圈 (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：修正 hypercall clobbers (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：修正轉送 fraglist GRO 的分割 (Jibin Zhang) [Orabug: 38970318] {CVE-2026-23154}
    - mm/shmem、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}
    - 藍牙：MGMT：修正 set_ssp_complete 中的記憶體洩漏 (Jianpeng Chang) [Orabug: 38970587] {CVE-2026-23151}
    - 藍牙：hci_uart：修正 hci_uart_write_work 中的 null-ptr-deref (Jia- Hong Su) [Orabug: 38970604] {CVE-2026-23146}
    - wifi：ath11k：在 reaping 監控目的地環時修正 RCU 停止 (P Praneesh) [Orabug: 37844129] {CVE-2024-58097}
    - btrfs：修正 btrfs_clear_space_info_full() 中的 racy 位元欄位寫入 (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}
    - 移轉：更正 hugetlb 檔案 folios 的鎖定順序 (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：修正輸出 open() 上的裝置洩漏 (Johan Hovold) [Orabug: 38931040] {CVE-2026-23091}
    - 追蹤：修正合成堆疊追蹤欄位使用時發生的當機問題 (Steven Rostedt) [Orabug: 38931024] {CVE-2026-23088}
    - arm64：在 swsusp_arch_resume() 上設定 __nocfi (Zhaoyang Huang) [Orabug: 38970241] {CVE-2026-23128}
    - arm64/fpsimd：訊號：還原 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() 中的釋放後使用 (Berk Cem Goksel) [Orabug: 38931029] {CVE-2026-23089}
    - ALSA：scarlett2：修正設定擷取中的緩衝區溢位 (Samasth Norway Ananda) [Orabug: 38930973] {CVE-2026-23078}
    - ALSA：ctxfi：修正音訊混音器處理中的潛在 OOB 存取 (Takashi Iwai) [Orabug: 38930966] {CVE-2026-23076}
    - leds：led-class：僅在 leds_list 完全準備就緒時，將 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}
    - 互連：debugfs：將 src_node 和 dst_node 初始化為空字串 (Georgi Djakov) [Orabug:
    38970218] {CVE-2026-23123}
    - io_uring/io-wq：檢查工作執行迴圈內的 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 中的差一緩衝區溢位 (Thorsten Blum) [Orabug: 38930796] {CVE-2025-71197}
    - crypto：authencesn - 拒絕過短 AAD (assoclen<8) 以符合 ESP/ESN 規格 (Taeyang Lee) [Orabug:
    38930874] {CVE-2026-23060}
    - net/sched：qfq：使用 cl_is_active 判斷 qfq_rm_from_ag 中的類別是否為使用中 (Jamal Hadi Salim) [Orabug: 38931110] {CVE-2026-23105}
    - net/sched：強制 teql 只能作為 root qdisc 使用 (Jamal Hadi Salim) [Orabug: 38930948] {CVE-2026-23074}
    - ipvlan：將 addrs_lock 設為各連接埠獨立擁有 (Dmitry Skorodumov) [Orabug: 38931102] {CVE-2026-23103}
    - l2tp：避免 l2tp_tunnel_del_work() 中的一個資料爭用情形 (Eric Dumazet) [Orabug: 38970202] {CVE-2026-23120}
    - gue：使用內部 IP 通訊協定 0 修正 skb memleak (Kuniyuki Iwashima) [Orabug: 38931057] {CVE-2026-23095}
    - sctp：將 SCTP_CMD_ASSOC_SHKEY 移到 SCTP_CMD_PEER_INIT 之後 (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() 中的 memleak  (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 核心中發現數個安全性問題。攻擊者可能會利用這些弱點入侵系統。此更新可更正下列子系統中的瑕疵：

    - Foo-over-UDP （FOU）;

    - ARM64 架構；

    - x86 架構;

    - 區塊層子系統 ;

    - 驅動程式核心；

    - Null 區塊裝置驅動程式 ;

    - 藍牙驅動程式;

    - 計數器介面驅動程式；

    - DMA 引擎子系統;

    - DPLL 子系統；

    - GPIO 子系統；

    - GPU 驅動程式；

    - I2C 子系統；

    - IIO ADC 驅動程式；

    - IIO 子系統；

    - InfiniBand 驅動程式；

    - 晶片上互連管理架構；

    - IOMMU 子系統;

    - IRQ 晶片驅動程式；

    - 模組化 ISDN 驅動程式；

    - LED 子系統；

    - 多個裝置驅動程式；

    - 媒體驅動程式；

    - UACCE 加速器架構；

    - MMC 子系統；

    - 乙太網路綁定驅動程式 ;

    - 網路驅動程式；

    - Mellanox 網路驅動程式；

    - Texas Instruments 網路驅動程式；

    - NVME 驅動程式；

    - 裝置樹狀結構和開放韌體驅動程式 ;

    - PHY 驅動程式；

    - x86 平台驅動程式；

    - i.MX PM 網域；

    - SCSI 子系統；

    - SLIMbus 驅動程式;

    - SPI 子系統；

    - TTY 驅動程式；

    - USB 主機控制器驅動程式；

    - W1 Dallas 的單線匯流排驅動程式；

    - Xen Hypervisor 驅動程式；

    - BTRFS 檔案系統；

    - EFI 變數檔案系統；

    - 檔案系統基礎架構；

    - Ext4 檔案系統；

    - FUSE (使用者空間中的檔案系統)；

    - 網路檔案系統程式庫；

    - 網路檔案系統 (NFS) 用戶端；

    - 網路檔案系統 (NFS) 伺服器程序；

    - SMB 網路檔案系統；

    - 記憶體管理 ;

    - 記憶體管理；

    - 排程器基礎架構；

    - 追蹤基礎架構；

    - IPv4 網路；

    - Netfilter；

    - NFC 子系統 ;

    - 網路流量控制；

    - TCP 網路通訊協定；

    - io_uring 子系統;

    - Perf 事件；

    - 鎖定基元 ;

    - 休眠控制；

    - Timer 子系統;

    - BPF 子系統；

    - 浮動比例庫；

    - 藍牙子系統；

    - CAN 網路層；

    - Ceph Core 程式庫；

    - 網路核心；

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

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	名稱	產品	系列	已發布	已更新	嚴重性
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
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
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 即時 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

偵測

搜尋 Plugin

high

medium

medium

critical

critical

high

medium