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.

Detections

Analytics

AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2025:1751916475)

high Nessus Plugin ID 360282

Version 1.2