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

  - In the Linux kernel, the following vulnerability has been resolved: ext4: add EXT4_IGET_BAD flag to     prevent unexpected bad inode There are many places that will get unhappy (and crash) when ext4_iget()     returns a bad inode. However, if iget the boot loader inode, allows a bad inode to be returned, because     the inode may not be initialized. This mechanism can be used to bypass some checks and cause panic. To     solve this problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag we'd be returning bad     inode from ext4_iget(), otherwise we always return the error code if the inode is bad inode.(suggested by     Jan Kara) (CVE-2022-50485)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search     caused by bad boot loader inode We got a issue as fllows:
    ================================================================== kernel BUG at     fs/ext4/extents_status.c:203! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted     6.0.0-next-20221007-dirty #349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS:
    00010203 RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000 RDX: 0000000000000000 RSI:
    ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8     R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14:
    00000000768e52f0 R15: 0000000000000000 FS:
    00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230     ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30     ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50     read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70     page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110     filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250     ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK>     ================================================================== In the above issue, ioctl invokes the     swap_inode_boot_loader function to swap inode<5> and inode<12>. However, inode<5> contain incorrect imode     and disordered extents, and i_nlink is set to 1. The extents check for inode in the ext4_iget function can     be bypassed bacause 5 is EXT4_BOOT_LOADER_INO. While links_count is set to 1, the extents are not     initialized in swap_inode_boot_loader. After the ioctl command is executed successfully, the extents are     swapped to inode<12>, in this case, run the `cat` command to view inode<12>. And Bug_ON is triggered due     to the incorrect extents. When the boot loader inode is not initialized, its imode can be one of the     following: 1) the imode is a bad type, which is marked as bad_inode in ext4_iget and set to S_IFREG. 2)     the imode is good type but not S_IFREG. 3) the imode is S_IFREG. The BUG_ON may be triggered by bypassing     the check in cases 1 and 2. Therefore, when the boot loader inode is bad_inode or its imode is not     S_IFREG, initialize the inode to avoid triggering the BUG. (CVE-2022-50638)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search     caused by bad quota inode We got a issue as fllows:
    ================================================================== kernel BUG at     fs/ext4/extents_status.c:202! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 810 Comm: mount Not     tainted 6.1.0-rc1-next-g9631525255e3 #352 RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0 RSP:
    0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000     RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08:
    47ffffffffffffff R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10     R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS:
    00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110     ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50     ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/0x90     v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190     ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0     get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/0xfc0     do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80     entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK>     ================================================================== Above issue may happen as follows:
    ------------------------------------- ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas     ext4_quota_enable ext4_iget --> get error inode <5> ext4_ext_check_inode --> Wrong imode makes it escape     inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode     vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header     ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent     ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger     BUG_ON In the above issue, s_usr_quota_inum is set to 5, but inode<5> contains incorrect imode and     disordered extents. Because 5 is EXT4_BOOT_LOADER_INO, the ext4_ext_check_inode check in the ext4_iget     function can be bypassed, finally, the extents that are not checked trigger the BUG_ON in the
    __es_tree_search function. To solve this issue, check whether the inode is bad_inode in     vfs_setup_quota_inode(). (CVE-2022-50782)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Handle EBUSY correctly     As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases     it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also     need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-     free. (CVE-2023-53373)

  - In the Linux kernel, the following vulnerability has been resolved: drm/radeon: free iio for atombios when     driver shutdown Fix below kmemleak when unload radeon driver: unreferenced object 0xffff9f8608ede200 (size     512): comm systemd-udevd, pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00     00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>]     atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon]     [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0     [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>]     drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>]     pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>]
    __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>]
    __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>]     driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio was allocated in     atom_index_iio() called by atom_parse(), but it doesn't got released when the dirver is shutdown. Fix this     kmemleak by free it in radeon_atombios_fini(). (CVE-2023-53453)

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:1762171389)

high Nessus Plugin ID 361580

Version 1.2

Version 1.1

Version 1.2 Oct 20, 2026, 12:55 PM CVE (set "CVE" coverage to "CVE-2022-50485,CVE-2022-50638,CVE-2022-50782,CVE-2023-53373,CVE-2023-53453,CVE-2023-53483,CVE-2023-53623,CVE-2023-53655,CVE-2023-53657,CVE-2023-53663,CVE-2024-35814,CVE-2024-40989,CVE-2024-56570,CVE-2024-56633,CVE-2025-38556,CVE-2025-39757") Detection (updated detection logic) Plugin metadata Plugin Feed: 202610201255
Version 1.1 Oct 1, 2026, 9:59 PM New Plugin Feed: 202610012159