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

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall     when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a     bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC:
    rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00     00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets     NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8     ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878]     rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [     226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ?     create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0     [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724]     ret_from_fork+0x35/0x40 ... (CVE-2022-49321)

  - In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in     unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held     and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of     unix_recvq_full(), otherwise KCSAN will report a data-race. (CVE-2022-49344)

  - In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when     threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the     previously allocated threshold banks array @bp will be leaked because the call to     mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches     the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank     creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all     the bank creation work previously done and pass into it the previously allocated threshold banks array for     freeing. [ bp: Massage. ] (CVE-2022-49549)

  - In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix uninit-value in     mpol_rebind_policy() mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when pol->mode is     MPOL_LOCAL. Check pol->mode before access pol->w.cpuset_mems_allowed in     mpol_rebind_policy()(mm/mempolicy.c). BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352     [inline] BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy     mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask     kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278     cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate     kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804
    __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0     kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852     kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline]     new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590     ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write     fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64     arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82     entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524     [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline]     kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline]     do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline]
    __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507
    __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline]     do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae KMSAN: uninit-     value in mpol_rebind_task (2)     https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc This patch seems to fix     below bug too. KMSAN: uninit-value in mpol_rebind_mm (2)     https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b The uninit-value is     pol->w.cpuset_mems_allowed in mpol_rebind_policy(). When syzkaller reproducer runs to the beginning of     mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c `mode` is     1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags` is 0. Then mode = MPOL_LOCAL; ...
    policy->mode = mode; policy->flags = flags; will be executed. So in mpol_set_nodemask(),     mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind() pol->mode is 4 (MPOL_LOCAL), that `nodemask`     in `pol` is not initialized, which will be accessed in mpol_rebind_policy(). (CVE-2022-49567)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: piix4: Fix a memory leak in the     EFCH MMIO support The recently added support for EFCH MMIO regions introduced a memory leak in that code     path. The leak is caused by the fact that release_resource() merely removes the resource from the tree but     does not free its memory. We need to call release_mem_region() instead, which does free the memory. As a     nice side effect, this brings back some symmetry between the legacy and MMIO paths. (CVE-2022-49653)

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-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1778769697)

high Nessus Plugin ID 362341

Version 1.2