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

  - A read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket     file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race     condition. This flaw allows a local user to crash the system or escalate their privileges on the system.
    This flaw affects Linux kernel versions prior to 5.16-rc4. (CVE-2021-4083)

  - A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the     small table perturb size. This flaw may allow an attacker to information leak and may cause a denial of     service problem. (CVE-2022-1012)

  - The vmwgfx driver contains a local privilege escalation vulnerability that allows unprivileged users to     gain access to files opened by other processes on the system through a dangling 'file' pointer.
    (CVE-2022-22942)

  - A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and     net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap     objects and may cause a local privilege escalation threat. (CVE-2022-27666)

  - In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors     on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file     descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file'     object through that still valid file descriptor, leading to all kinds of use-after-free exploitation     scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded.
    (CVE-2022-48771)

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

An update of the linux package has been released.

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2024:1731348593 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb     and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is     16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is     used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum,     BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16     And replace sprintf with snprintf. Detected using the static analysis tool - Svace. (CVE-2024-43839)

  - In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect     labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects     to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets     are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to     write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack     in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule     'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a     program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener     at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data     in both directions. * Collect network traffic of this connection. All packets in both directions are     labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized,     and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This     behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no     explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the     Smack documentation claims. (CVE-2024-47659)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr     changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is     changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds     access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem     00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity     change from 2048 to 2047 ================================================================== BUG: KASAN:
    use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f     by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted     6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS     1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline]     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline]     print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601     ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
    __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]     ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633     filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat     fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0     fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230     arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00     00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b     4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP:
    002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX:
    0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0     RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11:
    0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0     </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a     check of the validity of the xattrs, avoiding this problem. (CVE-2024-47701)

  - In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal     Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where     the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel     where firmware file names contain string components that are passed through from a device or semi-     privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: -     lpfc_sli4_request_firmware_update() seems to construct the firmware filename from ModelName, a string     that was previously parsed out of some descriptor (Vital Product Data) in lpfc_fill_vpd() -     nfp_net_fw_find() seems to construct a firmware filename from a model name coming from     nfp_hwinfo_lookup(pf->hwinfo, nffw.partno), which I think parses some descriptor that was read from the     device. (But this case likely isn't exploitable because the format string looks like netronome/nic_%s,     and there shouldn't be any *folders* starting with netronome/nic_. The previous case was different     because there, the %s is *at the start* of the format string.) - module_flash_fw_schedule() is reachable     from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning     CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-     provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network     namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack     path in practice.) Fix it by rejecting any firmware names containing .. path components. For what it's     worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.
    (CVE-2024-47742)

  - In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM     hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't     contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and     remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX,     bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the     remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker     to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same     thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz =     sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, test, 0); const char *buf = mmap(NULL, 4 *     pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality,     0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz,     0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd     = open(/proc/self/maps, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024);
    if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx     7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]     (CVE-2024-47745)

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

  - In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: fix shift-out-of-bounds     in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot     be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]     dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241     [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654     vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64     arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned     long, we should define these macros with same type too. (CVE-2022-50497)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer     overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid     req->dst buffer overflow problem. (CVE-2023-52612)

  - In the Linux kernel, the following vulnerability has been resolved: loop: Fix use-after-free issues     do_req_filebacked() calls blk_mq_complete_request() synchronously or asynchronously when using     asynchronous I/O unless memory allocation fails. Hence, modify loop_handle_cmd() such that it does not     dereference 'cmd' nor 'rq' after do_req_filebacked() finished unless we are sure that the request has not     yet been completed. This patch fixes the following kernel crash: Unable to handle kernel NULL pointer     dereference at virtual address 0000000000000054 Call trace: css_put.42938+0x1c/0x1ac     loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558     worker_thread+0x400/0x8fc kthread+0x16c/0x1e0 ret_from_fork+0x10/0x20 (CVE-2023-53111)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset +     VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the     allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]     BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds     in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-     executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat     KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description     mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433     kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic     lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472     drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol     drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812     ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e     drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 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/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP:
    0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
    ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40     RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000     R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38     kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline]
    ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525     kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc     include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]     create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]     ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603     drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965     ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 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/0x213 fs/ioctl.c:856     do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which     belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte     region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page:
    page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36     head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags:
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300     dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated--- (CVE-2023-53265)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: Better handle     pm_runtime_get() failing in .remove() In the (unlikely) event that pm_runtime_get() (disguised as     pm_runtime_resume_and_get()) fails, the remove callback returned an error early. The problem with this is     that the driver core ignores the error value and continues removing the device. This results in a resource     leak. Worse the devm allocated resources are freed and so if a callback of the driver is called later the     register mapping is already gone which probably results in a crash. (CVE-2023-53308)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
366964	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2024:1731430561)	Nessus	CentOS Local Security Checks	2026/10/18	2026/10/19	critical
332556	Photon OS 5.0: Linux PHSA-2024-5.0-91-0393	Nessus	PhotonOS Local Security Checks	2026/8/5	2026/11/2	critical
352214	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2024:1731348593)	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
352841	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778276927)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/22	high

検出

プラグインの検索

critical

critical

high

high