The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1784275029 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic     ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had     registered two ops with the same content successively, both dynamic. After unregistering the second ops, a     use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the     FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also,     both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the     FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and     ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is     released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1]     BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-     after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr     ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7     Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c     arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack     lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118     print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report     mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline     mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func     kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049     ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault     mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user     lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139     getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445:
    kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline]
    __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c     mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924     mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline]     perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733     [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline]
    __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80     kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48     kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358
    __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445     [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline]     slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10     mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc     kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline]
    __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...] (CVE-2022-49892)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to     freed memory Most users after parsing a topology file, release memory used by it, so having pointer     references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as     needed. (CVE-2024-41069)

  - In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption     request handling from async If we're not doing async, the handling is much simpler. There's no reference     counting, we just need to wait for the completion to wake us up and return its result. We should     preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think     aec7961916f3 (tls: fix race between async notify and socket close) took care of it. This will make the     next fix easier. (CVE-2024-58240)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op     runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The     content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe'     counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can     be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of     concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
    At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this     variable can be modified from both contexts too. (CVE-2025-38004)

  - In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue     originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel     function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index     (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI     is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by     their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets.
    Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail,     resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is     uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently     reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max =     0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each     using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a     duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently     reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation:
    xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same     SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in     different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a     result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change:
    xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket     and matches SPI and proto. (CVE-2025-39797)

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 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1784275029)

high Nessus Plugin ID 352747

Version 1.2