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

  - In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix bulk-buffer     overflow The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of     equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk     transfers. (CVE-2021-47474)

  - In the Linux kernel, the following vulnerability has been resolved: net: ena: fix shift-out-of-bounds in     exponential backoff The ENA adapters on our instances occasionally reset. Once recently logged a UBSAN     failure to console in the process: UBSAN: shift-out-of-bounds in     build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit     type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware     name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena ena_fw_reset_device [ena] Call Trace:
    <TASK> dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36
    __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e ? __const_udelay+0x43/0x50     ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] wait_for_reset_state+0x54/0xa0 [ena]     ena_com_dev_reset+0xc8/0x110 [ena] ena_down+0x3fe/0x480 [ena] ena_destroy_device+0xeb/0xf0 [ena]     ena_fw_reset_device+0x30/0x50 [ena] process_one_work+0x22b/0x3d0 worker_thread+0x4d/0x3f0 ?     process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30     </TASK> Apparently, the reset delays are getting so large they can trigger a UBSAN panic. Looking at the     code, the current timeout is capped at 5000us. Using a base value of 100us, the current code will overflow     after (1<<29). Even at values before 32, this function wraps around, perhaps unintentionally. Cap the     value of the exponent used for this backoff at (1<<16) which is larger than currently necessary, but large     enough to support bigger values in the future. (CVE-2023-53272)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on     PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
    However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not     checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()     R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
    (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,     smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
    frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =     1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))     R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)     ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and     finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]     Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run     include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]     bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350     net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359     bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
    __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
    __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]     do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by     rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7     pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)

  - In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When     both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on     device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code     paths, which both release either drvdata or hwmon and either can be released before the other. These code     paths (for device unbind) are as follows (see also the bug referenced below): Call Trace:
    release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0     component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915]     i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0     device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70     devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200     unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be     released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been     released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free     everything explicitly during device unbind. v2: Change commit message and other minor code changes v3:
    Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning     (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return     (Andi) (CVE-2024-39479)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer     dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to     transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap     tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still     pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does:
    get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to     NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL.
    get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle     page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF:
    error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI     RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: <TASK>     ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit     (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit     (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802)     neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237)
    __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb     (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485)     inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev =     slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with     properly allocated tstats. (CVE-2026-23277)

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

high Nessus Plugin ID 352448

Version 1.2