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.

Detections

Analytics

Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1782382498)

medium Nessus Plugin ID 351765

Version 1.3

Version 1.2

Version 1.1

Version 1.3 Oct 19, 2026, 10:23 AM Exploit attributes ("Exploit framework core" set to "True") Plugin Feed: 202610191023
Version 1.2 Oct 18, 2026, 10:57 AM CVE (set "CVE" coverage to "CVE-2022-49357,CVE-2023-53627,CVE-2024-36938,CVE-2024-53219,CVE-2025-21846,CVE-2025-37945,CVE-2025-38232,CVE-2025-38546,CVE-2025-40321,CVE-2025-68183,CVE-2025-71118,CVE-2025-71125,CVE-2026-23005,CVE-2026-23118,CVE-2026-23212,CVE-2026-23276,CVE-2026-23368,CVE-2026-23372,CVE-2026-23393,CVE-2026-23398,CVE-2026-31622,CVE-2026-31659,CVE-2026-46331") CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:F/RL:OF/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:F/RL:O/RC:C") Detection (updated detection logic) Plugin metadata Plugin Feed: 202610181057
Version 1.1 Sep 30, 2026, 9:32 PM New Plugin Feed: 202609302132