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

  - A flaw was found in the Linux kernel that allows the userspace to call memcpy_fromiovecend() and similar     functions with a zero offset and buffer length which causes the read beyond the buffer boundaries, in     certain cases causing a memory access fault and a system halt by accessing invalid memory address. This     issue only affects kernel version 3.10.x as shipped with Red Hat Enterprise Linux 7. (CVE-2018-16885)

  - An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in     drivers/media/pci/saa7134/saa7134-core.c. (CVE-2023-35823)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read     in rxe_queue_cleanup bug Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline]     dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline]     print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602     rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50     drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232     rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90     drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120     drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90     drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0     fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52     [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In     the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle     the allocated resources. In fact, some memory resources have already been freed in the function     rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work.
    (CVE-2025-38024)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in     ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a     mismatched user MAD header size and RMPP header length, data_len can become negative and reach     ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-     bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating     the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in     ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task     spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80     (CVE-2026-23243)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0     LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer     (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN     responses and does not account for LOCK denied responses, which include the conflicting lock owner as a     variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a     conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded     response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This     results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent     heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0     clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke     the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would     increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by     checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If     the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still     cached, and the client already received the correct response on the original request. (CVE-2026-31402)

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

Detections

Analytics

CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1785561693)

high Nessus Plugin ID 361392

Version 1.2