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

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Ensure rdma_addr_cancel()     happens before issuing more requests The FSM can run in a circle allowing rdma_resolve_ip() to be called     twice on the same id_priv. While this cannot happen without going through the work, it violates the     invariant that the same address resolution background request cannot be active twice. CPU 1 CPU 2     rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1     process_one_req(): for #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND     mutex_unlock(&id_priv->handler_mutex); [.. handler still running ..] rdma_resolve_addr():
    RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) !! two requests are now on the     req_list rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation():
    rdma_addr_cancel() // process_one_req() self removes it spin_lock_bh(&lock);
    cancel_delayed_work(&req->work); if (!list_empty(&req->list)) == true ! rdma_addr_cancel() returns after     process_on_req #1 is done kfree(id_priv) process_one_req(): for #2 addr_handler():
    mutex_lock(&id_priv->handler_mutex); !! Use after free on id_priv rdma_addr_cancel() expects there to be     one req on the list and only cancels the first one. The self-removal behavior of the work only happens     after the handler has returned. This yields a situations where the req_list can have two reqs for the same     handle but rdma_addr_cancel() only cancels the first one. The second req remains active beyond     rdma_destroy_id() and will use-after-free id_priv once it inevitably triggers. Fix this by remembering if     the id_priv has called rdma_resolve_ip() and always cancel before calling it again. This ensures the     req_list never gets more than one item in it and doesn't cost anything in the normal flow that never uses     this strange error path. (CVE-2021-47391)

  - In the Linux kernel, the following vulnerability has been resolved: writeback: avoid use-after-free after     removing device When a disk is removed, bdi_unregister gets called to stop further writeback and wait for     associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation     dwork after this has completed, which can result in the timer attempting to access the just freed     bdi_writeback. Fix this by checking if the bdi_writeback is alive, similar to when scheduling writeback     work. Since this requires wb->work_lock, and wb_inode_writeback_end() may get called from interrupt,     switch wb->work_lock to an irqsafe lock. (CVE-2022-49995)

  - An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux     kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol.
    (CVE-2023-39197)

  - In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in     skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a     forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily :
    mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final     result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1]     general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP     KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-     executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30     net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48     b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84     24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX:
    ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578     R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12:
    ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS:
    0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000     DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109     ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline]     validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338     dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276     packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119     sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto     net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3     e8 d1 19 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:00007fff8d685418 EFLAGS: 00000246     ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX:
    0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540     R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13:
    0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace     0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed     ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea     03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS:
    00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI:
    ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- (CVE-2023-52435)

  - In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on     context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func     function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that     might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check     before the invalid read reported by syzbot, within the context disconnection call stack. (CVE-2023-52445)

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.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2024:1711026811)

high Nessus Plugin ID 366955

Version 1.3

Version 1.2

Version 1.1

Version 1.3 Oct 19, 2026, 10:23 AM Exploit attributes ("Exploit framework core" set to "True") Exploit attributes ("Exploited by malware" set to "True") Plugin Feed: 202610191023
Version 1.2 Oct 18, 2026, 5:02 PM CVE (set "CVE" coverage to "CVE-2021-47391,CVE-2022-49995,CVE-2023-6356,CVE-2023-6535,CVE-2023-6536,CVE-2023-6546,CVE-2023-39197,CVE-2023-52435,CVE-2023-52445,CVE-2023-52449,CVE-2023-53333") Plugin metadata Plugin Feed: 202610181702
Version 1.1 Oct 18, 2026, 10:57 AM New Plugin Feed: 202610181057