In the Linux kernel, the following vulnerability has been resolved: nfsd: prevent panic for nfsv4.0 closed files in nfs4_show_open Prior to commit 3f29cc82a84c ("nfsd: split sc_status out of sc_type") states_show() relied on sc_type field to be of valid type before calling into a subfunction to show content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0 opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [ 513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0 [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896] seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2025:1753297988 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race on unaccepted mptcp     sockets When the listener socket owning the relevant request is closed, it frees the unaccepted subflows     and that causes later deletion of the paired MPTCP sockets. The mptcp socket's worker can run in the time     interval between such delete operations. When that happens, any access to msk->first will cause an UaF     access, as the subflow cleanup did not cleared such field in the mptcp socket. Address the issue     explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on     the pending msk. Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while     still owning the subflow socket one. (CVE-2022-49669)

  - In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: add sanity check for     gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the     gsm->receive() function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only     called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to     initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur.
    Fix this by avoiding the call to gsm->receive() in case the function is not initialized by adding a     sanity check. Call Trace: <TASK> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti     drivers/tty/tty_io.c:2293 [inline] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd     (CVE-2022-49940)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: clear optc underflow     before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and     clear not work. We need to clear that before clock off. [How] Clear that if have when clock off.
    (CVE-2022-49969)

  - In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix aq_vec index out of     range error The final update statement of the for loop exceeds the array range, the dereference of     self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of     coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in     drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type     'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610]     Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue:
    events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619]     dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [     97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632]     ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644]     aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [     97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657]     dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70     [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666]     worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [     97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK>     v2. fixed warning: variable 'aq_vec' set but not used v3. simplified a for loop (CVE-2022-50066)

  - In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: Fix a use-after-free bug     in open If someone cancels the open RPC call, then we must not try to free either the open slot or the     layoutget operation arguments, since they are likely still in use by the hung RPC call. (CVE-2022-50072)

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.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2025:1751916475 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in     shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure     that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs     don't hold their own references to pages that are mirrored over, so failing to notify them can lead to     page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b     (khugepaged: add support of collapse for tmpfs/shmem pages), but most of the security impact of this     only came in commit 27e1f8273113 (khugepaged: enable collapse pmd for pte-mapped THP), which actually     omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
    (CVE-2022-48991)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: prevent panic for nfsv4.0 closed     files in nfs4_show_open Prior to commit 3f29cc82a84c (nfsd: split sc_status out of sc_type)     states_show() relied on sc_type field to be of valid type before calling into a subfunction to show     content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and     no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0     opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed     open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the     server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [     513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0     [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896]     seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178     (CVE-2024-46682)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in     FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a     possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the     client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(),     that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the     stateid which leads to either use-after-free or decrementing already zeroed counter. (CVE-2024-50043)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs     attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can     take different parameters or return different return values. If prog attached to one kernel function tail     calls prog attached to another kernel function, the ctx access or return value verification could be     bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to     func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based     on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it.
    The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In     this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption     for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook     file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the     return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive     number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to     return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier     does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used     as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This     patch adds restriction for tail call to prevent such bypasses. (CVE-2024-50063)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: fix race between laundromat and     free_stateid There is a race between laundromat handling of revoked delegations and a client sending     free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it     marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and     the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing     free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the     reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the     revoke_delegation() function for this particular delegation but that means it will no release the lock     lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list     isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation     stateid. Leading to the followint use-after-free KASAN warning: kernel:
    ================================================================== kernel: BUG: KASAN: slab-use-after-free     in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task     nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9     kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024     kernel: Call trace: kernel: dump_backtrace+0x98/0x120 kernel: show_stack+0x1c/0x30 kernel:
    dump_stack_lvl+0x80/0xe8 kernel: print_address_description.constprop.0+0x84/0x390 kernel:
    print_report+0xa4/0x268 kernel: kasan_report+0xb4/0xf8 kernel: __asan_report_load8_noabort+0x1c/0x28     kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]     kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd] kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd] kernel:
    nfsd4_process_open2+0xa40/0x1a40 [nfsd] kernel: nfsd4_open+0xa08/0xe80 [nfsd] kernel:
    nfsd4_proc_compound+0xb8c/0x2130 [nfsd] kernel: nfsd_dispatch+0x22c/0x718 [nfsd] kernel:
    svc_process_common+0x8e8/0x1960 [sunrpc] kernel: svc_process+0x3d4/0x7e0 [sunrpc] kernel:
    svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd]     kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 This patch proposes a fixed that's based on     adding 2 new additional stid's sc_status values that help coordinate between the laundromat and other     operations (nfsd4_free_stateid() and nfsd4_delegreturn()). First to make sure, that once the stid is     marked revoked, it is not removed by the nfsd4_free_stateid(), the laundromat take a reference on the     stateid. Then, coordinating whether the stid has been put on the cl_revoked list or we are processing     FREE_STATEID and need to make sure to remove it from the list, each check that state and act accordingly.
    If laundromat has added to the cl_revoke list before the arrival of FREE_STATEID, then     nfsd4_free_stateid() knows to remove it from the list. If nfsd4_free_stateid() finds that operations     arrived before laundromat has placed it on cl_revoke list, it marks the state freed and then laundromat     will no longer add it to the list. Also, for nfsd4_delegreturn() when looking for the specified stid, we     need to access stid that are marked removed or freeable, it means the laundromat has started processing it     but hasn't finished and this delegreturn needs to return nfserr_deleg_revoked and not nfserr_bad_stateid.
    The latter will not trigger a FREE_STATEID and the lack of it will leave this stid on the cl_revoked list     indefinitely. (CVE-2024-50106)

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

The CentOS Linux 8.5 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.5:CLSA-2025:1753298320 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ath11k: free peer for station when     disconnect from AP for QCA6390/WCN6855 Commit b4a0f54156ac (ath11k: move peer delete after vdev stop of     station for QCA6390 and WCN6855) is to fix firmware crash by changing the WMI command sequence, but     actually skip all the peer delete operation, then it lead commit 58595c9874c6 (ath11k: Fixing dangling     pointer issue upon peer delete failure) not take effect, and then happened a use-after-free warning from     KASAN. because the peer->sta is not set to NULL and then used later. Change to only skip the     WMI_PEER_DELETE_CMDID for QCA6390/WCN6855. log of user-after-free: [ 534.888665] BUG: KASAN: use-after-     free in ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888696] Read of size 8 at addr     ffff8881396bb1b8 by task rtcwake/2860 [ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted:
    G W 5.15.0-wt-ath+ #523 [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS     HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 534.888716] Call Trace: [ 534.888720] <IRQ> [ 534.888726]     dump_stack_lvl+0x57/0x7d [ 534.888736] print_address_description.constprop.0+0x1f/0x170 [ 534.888745] ?     ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888771] kasan_report.cold+0x83/0xdf [     534.888783] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888810]     ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k] [ 534.888840]     ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k] [ 534.888874] ?     ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k] [ 534.888897] ? check_prev_add+0x20f0/0x20f0 [     534.888922] ? __lock_acquire+0xb72/0x1870 [ 534.888937] ? find_held_lock+0x33/0x110 [ 534.888954]     ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k] [ 534.888981] ? rcu_read_unlock+0x40/0x40 [     534.888990] ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k] [ 534.889026]     ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k] [ 534.889053] ? ath11k_dp_rx_process_mon_rings+0x520/0x520     [ath11k] [ 534.889075] call_timer_fn+0x167/0x4a0 [ 534.889084] ? add_timer_on+0x3b0/0x3b0 [ 534.889103] ?     lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 534.889117] __run_timers.part.0+0x539/0x8b0 [ 534.889123]     ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k] [ 534.889157] ? call_timer_fn+0x4a0/0x4a0 [     534.889164] ? mark_lock_irq+0x1c30/0x1c30 [ 534.889173] ? clockevents_program_event+0xdd/0x280 [     534.889189] ? mark_held_locks+0xa5/0xe0 [ 534.889203] run_timer_softirq+0x97/0x180 [ 534.889213]
    __do_softirq+0x276/0x86a [ 534.889230] __irq_exit_rcu+0x11c/0x180 [ 534.889238] irq_exit_rcu+0x5/0x20 [     534.889244] sysvec_apic_timer_interrupt+0x8e/0xc0 [ 534.889251] </IRQ> [ 534.889254] <TASK> [ 534.889259]     asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 [     534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02     75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee     [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206 [ 534.889284] RAX: 0000000000000006 RBX:
    0000000000000200 RCX: ffffffff9f256f10 [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI:
    0000000000000001 [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f [     534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68 [ 534.889302] R13:
    ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000 [ 534.889316] ? mark_lock+0xd0/0x14a0 [     534.889332] klist_next+0x1d4/0x450 [ 534.889340] ? dpm_wait_for_subordinate+0x2d0/0x2d0 [ 534.889350]     device_for_each_child+0xa8/0x140 [ 534.889360] ? device_remove_class_symlinks+0x1b0/0x1b0 [ 534.889370] ?
    __lock_release+0x4bd/0x9f0 [ 534.889378] ? dpm_suspend+0x26b/0x3f0 [ 534.889390] dpm_wait_for_subordinate+
    ---truncated--- (CVE-2022-49238)

  - In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: add sanity check for     gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the     gsm->receive() function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only     called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to     initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur.
    Fix this by avoiding the call to gsm->receive() in case the function is not initialized by adding a     sanity check. Call Trace: <TASK> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti     drivers/tty/tty_io.c:2293 [inline] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd     (CVE-2022-49940)

  - In the Linux kernel, the following vulnerability has been resolved: net: qrtr: start MHI channel after     endpoit creation MHI channel may generates event/interrupt right after enabling. It may leads to 2 race     conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev ||     mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at     this moment. In this situation qrtr-ns will be unable to enumerate services in device.
    --------------------------------------------------------------- 2) Such event may come at the moment after     dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong     pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr,     mhi_res->bytes_xferd); Because endpoint is not created yet.
    -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue     after endpoint creation to fix it. (CVE-2022-50044)

  - In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix aq_vec index out of     range error The final update statement of the for loop exceeds the array range, the dereference of     self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of     coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in     drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type     'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610]     Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue:
    events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619]     dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [     97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632]     ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644]     aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [     97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657]     dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70     [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666]     worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [     97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK>     v2. fixed warning: variable 'aq_vec' set but not used v3. simplified a for loop (CVE-2022-50066)

  - In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: Fix a use-after-free bug     in open If someone cancels the open RPC call, then we must not try to free either the open slot or the     layoutget operation arguments, since they are likely still in use by the hung RPC call. (CVE-2022-50072)

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.

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: prevent panic for nfsv4.0 closed     files in nfs4_show_open Prior to commit 3f29cc82a84c (nfsd: split sc_status out of sc_type)     states_show() relied on sc_type field to be of valid type before calling into a subfunction to show     content of a particular stateid. From that commit, we split the validity of the stateid into sc_status and     no longer changed sc_type to 0 while unhashing the stateid. This resulted in kernel oopsing for nfsv4.0     opens that stay around and in nfs4_show_open() would derefence sc_file which was NULL. Instead, for closed     open stateids forgo displaying information that relies of having a valid sc_file. To reproduce: mount the     server with 4.0, read and close a file and then on the server cat /proc/fs/nfsd/clients/2/states [     513.590804] Call trace: [ 513.590925] _raw_spin_lock+0xcc/0x160 [ 513.591119] nfs4_show_open+0x78/0x2c0     [nfsd] [ 513.591412] states_show+0x44c/0x488 [nfsd] [ 513.591681] seq_read_iter+0x5d8/0x760 [ 513.591896]     seq_read+0x188/0x208 [ 513.592075] vfs_read+0x148/0x470 [ 513.592241] ksys_read+0xcc/0x178     (CVE-2024-46682)

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

ID	Name	Product	Family	Type	Severity
360874	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel-core / kernel-debug / kernel-debug-core / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2025:1753297988)	Nessus	CentOS Local Security Checks	Local	high
360282	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2025:1751916475)	Nessus	Alma Linux Local Security Checks	Local	high
351710	CentOS Linux 8.5 [TuxCare] Security Update: kernel-cross-headers / kernel-debug-modules-extra / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2025:1753298320)	Nessus	CentOS Local Security Checks	Local	high
248675	Linux Distros Unpatched Vulnerability : CVE-2024-46682	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2024-46682

medium

Tenable Plugins

high

high

high

medium