In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix data-race warning and potential load/store tearing Fix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet which is reporting an issue with the reads and writes to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds(); and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME; The lockless accesses to these to values aren't actually a problem as the read only needs an approximate time of last transmission for the purposes of deciding whether or not the transmission of a keepalive packet is warranted yet. Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit arch. Fix both of these by switching to an unsigned int for ->last_tx_at and only storing the LSW of the time64_t. It can then be reconstructed at need provided no more than 68 years has elapsed since the last transmission.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix data-race warning and
    potential load/store tearing Fix the following: BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker /
    rxrpc_send_data_packet which is reporting an issue with the reads and writes to ->last_tx_at in:
    conn->peer->last_tx_at = ktime_get_seconds(); and: keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;
    The lockless accesses to these to values aren't actually a problem as the read only needs an approximate
    time of last transmission for the purposes of deciding whether or not the transmission of a keepalive
    packet is warranted yet. Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit arch. Fix
    both of these by switching to an unsigned int for ->last_tx_at and only storing the LSW of the time64_t.
    It can then be reconstructed at need provided no more than 68 years has elapsed since the last
    transmission. (CVE-2026-23118)

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1786761805 advisory.

  - A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail     to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel     panic in the host (L0). (CVE-2022-3344)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1782382498 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1782382498 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

  - In the Linux kernel, the following vulnerability has been resolved: 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)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8669-1 advisory.

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - Foo-over-UDP (FOU);

    - ARM64 architecture;

    - x86 architecture;

    - Block layer subsystem;

    - Drivers core;

    - Null block device driver;

    - Bluetooth drivers;

    - Counter interface drivers;

    - DMA engine subsystem;

    - DPLL subsystem;

    - GPIO subsystem;

    - GPU drivers;

    - I2C subsystem;

    - IIO ADC drivers;

    - IIO subsystem;

    - InfiniBand drivers;

    - On-Chip Interconnect management framework;

    - IOMMU subsystem;

    - IRQ chip drivers;

    - Modular ISDN driver;

    - LED subsystem;

    - Multiple devices driver;

    - Media drivers;

    - UACCE accelerator framework;

    - MMC subsystem;

    - Ethernet bonding driver;

    - Network drivers;

    - Mellanox network drivers;

    - Texas Instruments network drivers;

    - NVME drivers;

    - Device tree and open firmware driver;

    - PHY drivers;

    - x86 platform drivers;

    - i.MX PM domains;

    - SCSI subsystem;

    - SLIMbus drivers;

    - SPI subsystem;

    - TTY drivers;

    - USB Host Controller drivers;

    - W1 Dallas's 1-wire bus driver;

    - Xen hypervisor drivers;

    - BTRFS file system;

    - EFI Variable file system;

    - File systems infrastructure;

    - Ext4 file system;

    - FUSE (File system in Userspace);

    - Network file systems library;

    - Network file system (NFS) client;

    - Network file system (NFS) server daemon;

    - SMB network file system;

    - Memory Management;

    - Memory management;

    - Scheduler infrastructure;

    - Tracing infrastructure;

    - IPv4 networking;

    - Netfilter;

    - NFC subsystem;

    - Network traffic control;

    - TCP network protocol;

    - io_uring subsystem;

    - Perf events;

    - Locking primitives;

    - Hibernation control;

    - Timer subsystem;

    - BPF subsystem;

    - Floating proportions library;

    - Bluetooth subsystem;

    - CAN network layer;

    - Ceph Core library;

    - Networking core;

    - IPv6 networking;

    - L2TP protocol;

    - MAC80211 subsystem;

    - Multipath TCP;

    - NET/ROM layer;

    - RxRPC session sockets;

    - SCTP protocol;

    - SMC sockets;

    - VMware vSockets driver;

    - Wireless networking;

    - ALSA AC97 driver;

    - Creative Sound Blaster X-Fi driver;

    - Texas InstrumentS Audio (ASoC/HDA) drivers;

    - USB sound devices; (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-22981, CVE-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-23055, CVE-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-23119, CVE-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 has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Oracle Linux 10 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-50160 advisory.

    - mm/hugetlb: fix hugetlb_pmd_shared() (David Hildenbrand) [Orabug: 38931087] {CVE-2026-23100}
    - platform/x86: classmate-laptop: Add missing NULL pointer checks (Rafael J. Wysocki) [Orabug: 39044501]     {CVE-2026-23237}
    - scsi: qla2xxx: Fix bsg_done() causing double free (Anil Gurumurthy) [Orabug: 39044457] {CVE-2025-71238}
    - wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add (Ali Tariq) [Orabug: 38997990]     {CVE-2025-71234}
    - xfs: fix UAF in xchk_btree_check_block_owner (Darrick J. Wong) [Orabug: 38998028] {CVE-2026-23223}
    - scsi: qla2xxx: Free sp in error path to fix system crash (Anil Gurumurthy) [Orabug: 38997979]     {CVE-2025-71232}
    - scsi: qla2xxx: Delay module unload while fabric scan in progress (Anil Gurumurthy) [Orabug: 38997992]     {CVE-2025-71235}
    - scsi: qla2xxx: Validate sp before freeing associated memory (Anil Gurumurthy) [Orabug: 38997998]     {CVE-2025-71236}
    - wifi: rtw88: Fix alignment fault in rtw_core_enable_beacon() (Bitterblue Smith) [Orabug: 38997972]     {CVE-2025-71229}
    - crypto: virtio - Add spinlock protection with virtqueue notification (Bibo Mao) [Orabug: 38998052]     {CVE-2026-23229}
    - crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode (Thorsten Blum) [Orabug:
    38997976] {CVE-2025-71231}
    - smb: client: split cached_fid bitfields to avoid shared-byte RMW races (Henrique Carvalho) [Orabug:
    38998059] {CVE-2026-23230}
    - spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer (Breno Leitao) [Orabug: 38970593]     {CVE-2026-23202}
    - ASoC: amd: fix memory leak in acp3x pdm dma ops (Chris Bainbridge) [Orabug: 38970441] {CVE-2026-23190}
    - ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF (Shigeru Yoshida) [Orabug: 38970598]     {CVE-2026-23200}
    - netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() (Andrew Fasano) [Orabug:
    38970170] {CVE-2026-23111}
    - net: usb: r8152: fix resume reset deadlock (Sergey Senozhatsky) [Orabug: 38970438] {CVE-2026-23188}
    - macvlan: fix error recovery in macvlan_common_newlink() (Eric Dumazet) [Orabug: 38970508]     {CVE-2026-23209}
    - net/sched: cls_u32: use skb_header_pointer_careful() (Eric Dumazet) [Orabug: 38970487] {CVE-2026-23204}
    - smb/client: fix memory leak in smb2_open_file() (Chenxiaosong) [Orabug: 38970578] {CVE-2026-23205}
    - btrfs: reject new transactions if the fs is fully read-only (Qu Wenruo) [Orabug: 38985156]     {CVE-2026-23214}
    - scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() (Maurizio Lombardi) [Orabug:
    38985169] {CVE-2026-23216}
    - scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count() (Maurizio Lombardi) [Orabug:
    38970453] {CVE-2026-23193}
    - nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready() (Hannes Reinecke) [Orabug: 38970416]     {CVE-2026-23179}
    - drm/amd/pm: Disable MMIO access during SMU Mode 1 reset (Perry Yuan) [Orabug: 38985149] {CVE-2026-23213}
    - HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report() (Kwok Kin Ming) [Orabug: 38970413]     {CVE-2026-23178}
    - md: suspend array while updating raid_disks via sysfs (Danny Shih) [Orabug: 38985108] {CVE-2025-71225}
    - wifi: wlcore: ensure skb headroom before skb_push (Peter Astrand) [Orabug: 38970152] {CVE-2025-71222}
    - wifi: mac80211: ocb: skip rx_no_sta when interface is not joined (Moon Hee Lee) [Orabug: 38970163]     {CVE-2025-71224}
    - procfs: avoid fetching build ID while holding VMA lock (Andrii Nakryiko) [Orabug: 38970476]     {CVE-2026-23199}
    - mm, shmem: prevent infinite loop on truncate race (Kairui Song) [Orabug: 38970409] {CVE-2026-23177}
    - ceph: fix oops due to invalid pointer for kfree() in parse_longname() (Daniel Vogelbacher) [Orabug:
    38970590] {CVE-2026-23201}
    - ceph: fix NULL pointer dereference in ceph_mds_auth_match() (Viacheslav Dubeyko) [Orabug: 38970595]     {CVE-2026-23189}
    - mm/slab: Add alloc_tagging_slab_free_hook for memcg_alloc_abort_single (Hao Ge) [Orabug: 38985192]     {CVE-2026-23219}
    - ALSA: aloop: Fix racy access at PCM trigger (Takashi Iwai) [Orabug: 38970445] {CVE-2026-23191}
    - x86/vmware: Fix hypercall clobbers (Josh Poimboeuf) [Orabug: 38985163] {CVE-2026-23215}
    - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec (Yunje Shin) [Orabug: 38970176]     {CVE-2026-23112}
    - perf: sched: Fix perf crash with new is_user_task() helper (Steven Rostedt) [Orabug: 38970581]     {CVE-2026-23159}
    - wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode (Kang Yang) [Orabug: 37844126]     {CVE-2024-58096}
    - drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove (Jon Doron) [Orabug:
    38970348] {CVE-2026-23163}
    - net: fix segmentation of forwarding fraglist GRO (Jibin Zhang) [Orabug: 38970318] {CVE-2026-23154}
    - mm/shmem, swap: fix race of truncate and swap entry split (Kairui Song) [Orabug: 38970345]     {CVE-2026-23161}
    - flex_proportions: make fprop_new_period() hardirq safe (Jan Kara) [Orabug: 38970373] {CVE-2026-23168}
    - nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference (Ming Lei) [Orabug: 38970608]     {CVE-2026-23148}
    - efivarfs: fix error propagation in efivar_entry_get() (Kohei Enju) [Orabug: 38970325] {CVE-2026-23156}
    - net/mlx5e: TC, delete flows only for existing peers (Mark Bloch) [Orabug: 38970397] {CVE-2026-23173}
    - ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues (Aaron Ma) [Orabug: 38970364]     {CVE-2026-23166}
    - rocker: fix memory leak in rocker_world_port_post_fini() (Kery Qi) [Orabug: 38970351] {CVE-2026-23164}
    - bonding: annotate data-races around slave->last_rx (Eric Dumazet) [Orabug: 38985142] {CVE-2026-23212}
    - Bluetooth: MGMT: Fix memory leak in set_ssp_complete (Jianpeng Chang) [Orabug: 38970587]     {CVE-2026-23151}
    - Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work (Jia-Hong Su) [Orabug: 38970604]     {CVE-2026-23146}
    - wifi: ath11k: fix RCU stall while reaping monitor destination ring (P Praneesh) [Orabug: 37844129]     {CVE-2024-58097}
    - btrfs: fix racy bitfield write in btrfs_clear_space_info_full() (Boris Burkov) [Orabug: 38798802]     {CVE-2025-68358}
    - sched_ext: Fix possible deadlock in the deferred_irq_workfn() (Zqiang) [Orabug: 38792605]     {CVE-2025-68333}
    - exfat: fix refcount leak in exfat_find (Shuhao Fu) [Orabug: 38798780] {CVE-2025-68351}
    - bpf: Do not let BPF test infra emit invalid GSO types to stack (Daniel Borkmann) [Orabug: 38798881]     {CVE-2025-68725}
    - migrate: correct lock ordering for hugetlb file folios (Matthew Wilcox) [Orabug: 38931066]     {CVE-2026-23097}
    - can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak (Marc Kleine-Budde) [Orabug: 38931120]     {CVE-2026-23108}
    - can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak (Marc Kleine-Budde) [Orabug:
    38930881] {CVE-2026-23061}
    - can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak (Marc Kleine-Budde) [Orabug: 38930859]     {CVE-2026-23058}
    - irqchip/gic-v3-its: Avoid truncating memory addresses (Arnd Bergmann) [Orabug: 38931001]     {CVE-2026-23085}
    - intel_th: fix device leak on output open() (Johan Hovold) [Orabug: 38931040] {CVE-2026-23091}
    - tracing: Fix crash on synthetic stacktrace field usage (Steven Rostedt) [Orabug: 38931024]     {CVE-2026-23088}
    - arm64: Set __nocfi on swsusp_arch_resume() (Zhaoyang Huang) [Orabug: 38970241] {CVE-2026-23128}
    - arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA (Mark Rutland) [Orabug: 38931118]     {CVE-2026-23107}
    - wifi: rsi: Fix memory corruption due to not set vif driver data size (Marek Vasut) [Orabug: 38930939]     {CVE-2026-23073}
    - wifi: ath10k: fix dma_free_coherent() pointer (Thomas Fourier) [Orabug: 38970253] {CVE-2026-23133}
    - ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() (Berk Cem Goksel) [Orabug: 38931029]     {CVE-2026-23089}
    - ALSA: scarlett2: Fix buffer overflow in config retrieval (Samasth Norway Ananda) [Orabug: 38930973]     {CVE-2026-23078}
    - ALSA: ctxfi: Fix potential OOB access in audio mixer handling (Takashi Iwai) [Orabug: 38930966]     {CVE-2026-23076}
    - leds: led-class: Only Add LED to leds_list when it is fully ready (Hans de Goede) [Orabug: 38931091]     {CVE-2026-23101}
    - dpll: Prevent duplicate registrations (Ivan Vecera) [Orabug: 38970244] {CVE-2026-23129}
    - vsock/virtio: cap TX credit to local buffer size (Melbin K Mathew) [Orabug: 38931008] {CVE-2026-23086}
    - vsock/virtio: fix potential underflow in virtio_transport_get_credit() (Melbin K Mathew) [Orabug:
    38930919] {CVE-2026-23069}
    - bonding: provide a net pointer to __skb_flow_dissect() (Eric Dumazet) [Orabug: 38970199]     {CVE-2026-23119}
    - be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list (Andrey Vatoropin) [Orabug: 38930992]     {CVE-2026-23084}
    - ipv6: annotate data-race in ndisc_router_discovery() (Eric Dumazet) [Orabug: 38970222] {CVE-2026-23124}
    - netdevsim: fix a race issue related to the operation on bpf_bound_progs list (Yun Lu) [Orabug: 38970233]     {CVE-2026-23126}
    - scsi: qla2xxx: Sanitize payload size to prevent member overflow (Jiasheng Jiang) [Orabug: 38930867]     {CVE-2026-23059}
    - scsi: core: Wake up the error handler when final completions race against each other (David Jeffery)     [Orabug: 38931132] {CVE-2026-23110}
    - regmap: Fix race condition in hwspinlock irqsave routine (Cheng-Yu Lee) [Orabug: 38930930]     {CVE-2026-23071}
    - interconnect: debugfs: initialize src_node and dst_node to empty strings (Georgi Djakov) [Orabug:
    38970218] {CVE-2026-23123}
    - io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop (Jens Axboe) [Orabug: 38970181]     {CVE-2026-23113}
    - platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro (Mario Limonciello) [Orabug:
    38930890] {CVE-2026-23062}
    - platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names (Mario Limonciello) [Orabug:
    38970247] {CVE-2026-23131}
    - scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() (Abdun Nihaal) [Orabug: 38931014]     {CVE-2026-23087}
    - w1: therm: Fix off-by-one buffer overflow in alarms_store (Thorsten Blum) [Orabug: 38930796]     {CVE-2025-71197}
    - crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec (Taeyang Lee) [Orabug:
    38930874] {CVE-2026-23060}
    - net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag (Jamal Hadi     Salim) [Orabug: 38931110] {CVE-2026-23105}
    - net/sched: Enforce that teql can only be used as root qdisc (Jamal Hadi Salim) [Orabug: 38930948]     {CVE-2026-23074}
    - ipvlan: Make the addrs_lock be per port (Dmitry Skorodumov) [Orabug: 38931102] {CVE-2026-23103}
    - l2tp: avoid one data-race in l2tp_tunnel_del_work() (Eric Dumazet) [Orabug: 38970202] {CVE-2026-23120}
    - gue: Fix skb memleak with inner IP protocol 0. (Kuniyuki Iwashima) [Orabug: 38931057] {CVE-2026-23095}
    - sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT (Xin Long) [Orabug: 38970225]     {CVE-2026-23125}
    - can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error (Marc Kleine-Budde)     [Orabug: 38931184] {CVE-2026-23082}
    - l2tp: Fix memleak in l2tp_udp_encap_recv(). (Kuniyuki Iwashima) [Orabug: 38930935] {CVE-2026-23072}
    - bonding: limit BOND_MODE_8023AD to Ethernet devices (Eric Dumazet) [Orabug: 38931079] {CVE-2026-23099}
    - vsock/virtio: Coalesce only linear skb (Michal Luczaj) [Orabug: 38930857] {CVE-2026-23057}

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - rxrpc: Fix data-race warning and potential load/store tearing Fix the following: BUG: KCSAN: data-race in     rxrpc_peer_keepalive_worker / rxrpc_send_data_packet which is reporting an issue with the reads and writes     to ->last_tx_at in: conn->peer->last_tx_at = ktime_get_seconds(); and: keepalive_at = peer->last_tx_at +     RXRPC_KEEPALIVE_TIME; The lockless accesses to these to values aren't actually a problem as the read only     needs an approximate time of last transmission for the purposes of deciding whether or not the     transmission of a keepalive packet is warranted yet. Also, as ->last_tx_at is a 64-bit value, tearing can     occur on a 32-bit arch. Fix both of these by switching to an unsigned int for ->last_tx_at and only     storing the LSW of the time64_t. It can then be reconstructed at need provided no more than 68 years has     elapsed since the last transmission. (CVE-2026-23118)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
455158	Echo: linux: security update to 6.12.69-1	Tenable Cloud Security	Echo Local Security Checks	Local	medium
455158	Echo: linux: security update to 6.12.69-1	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
352031	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	Local	critical
351765	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1782382498)	Nessus	Rocky Linux Local Security Checks	Local	medium
351608	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1782382498)	Nessus	Alma Linux Local Security Checks	Local	medium
340680	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (Raspberry Pi) vulnerabilities (USN-8665-1)	Nessus	Ubuntu Local Security Checks	Local	high
340678	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8669-1)	Nessus	Ubuntu Local Security Checks	Local	high
303468	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-50160)	Nessus	Oracle Linux Local Security Checks	Local	critical
299077	Linux Distros Unpatched Vulnerability : CVE-2026-23118	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-23118

medium

Tenable Plugins

medium

medium

critical

medium

medium

high

high

critical

medium