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

  - In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix use after free bugs     After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which     aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue.
    (CVE-2021-47670)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM     from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need     to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause     deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following     warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM     storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM     events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at     <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm:
    kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft     Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393]     Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130     <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414]
    __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418]     cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421]     del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427]     device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429]     bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432]
    __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434]     storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437]     worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [     14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace     2d9633159fdc6ee7 ]--- (CVE-2022-49986)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to     prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a     crash (null dereference) when using tproxy from e.g. output. (CVE-2022-50001)

  - In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-     balanced queue id Fix the following scenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Above     refers to a case where user would like to attach XSK socket in txonly mode at a queue id that does not     have a corresponding Rx queue. At this moment ice's XSK logic is tightly bound to act on a queue pair,     e.g. both Tx and Rx queues at a given queue id are disabled/enabled and both of them will get XSK pool     assigned, which is broken for the presented queue configuration. This results in the splat included at the     bottom, which is basically an OOB access to Rx ring array. To fix this, allow using the ids only in scope     of combined queues reported by ethtool. However, logic should be rewritten to allow such configurations     later on, which would end up as a complete rewrite of the control path, so let us go with this temporary     fix. [420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082 [420160.566359] #PF:
    supervisor read access in kernel mode [420160.572657] #PF: error_code(0x0000) - not-present page     [420160.579002] PGD 0 P4D 0 [420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI [420160.588396] CPU: 10 PID:
    21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10 [420160.597893] Hardware name: Intel Corporation     S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [420160.609894] RIP:
    0010:ice_xsk_pool_setup+0x44/0x7d0 [ice] [420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48     8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00     48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85 [420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282     [420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8 [420160.655893] RDX:
    0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000 [420160.665166] RBP: 000000000000000a R08:
    000000000000000a R09: 0000000000000000 [420160.674493] R10: 000000000000889f R11: 0000000000000000 R12:
    000000000000000a [420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828     [420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000     [420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [420160.711783] CR2: 0000000000000082     CR3: 00000001d076c001 CR4: 00000000007706e0 [420160.721399] DR0: 0000000000000000 DR1: 0000000000000000     DR2: 0000000000000000 [420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400     [420160.740707] PKRU: 55555554 [420160.745960] Call Trace: [420160.750962] <TASK> [420160.755597] ?     kmalloc_large_node+0x79/0x90 [420160.762703] ? __kmalloc_node+0x3f5/0x4b0 [420160.769341]     xp_assign_dev+0xfd/0x210 [420160.775661] ? shmem_file_read_iter+0x29a/0x420 [420160.782896]     xsk_bind+0x152/0x490 [420160.788943] __sys_bind+0xd0/0x100 [420160.795097] ?     exit_to_user_mode_prepare+0x20/0x120 [420160.802801] __x64_sys_bind+0x16/0x20 [420160.809298]     do_syscall_64+0x38/0x90 [420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd [420160.823731] RIP:
    0033:0x7fa86a0dd2fb [420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff     ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b     0c 00 f7 d8 64 89 01 48 [420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX:
    0000000000000031 [420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb     [420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003 [420160.887604] RBP:
    000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000 [420160.898293] R10: 0000000000008001 R11:
    0000000000000246 R12: 000055d7113a04e0 [420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15:
    0000000000000000 [420160.919817] </TASK> [420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc
    ---truncated--- (CVE-2022-50003)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda-ipc: Do not     process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so     broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will     arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL     pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same condition     is present for IPC3. (CVE-2022-50015)

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-2025:1757962453)

high Nessus Plugin ID 360866

Version 1.5

Version 1.4

Version 1.3

Version 1.2

Version 1.1

Version 1.5 Oct 19, 2026, 10:23 AM Exploit attributes ("Exploited by malware" set to "True") Plugin Feed: 202610191023
Version 1.4 Oct 18, 2026, 5:02 PM CVE (set "CVE" coverage to "CVE-2021-47103,CVE-2021-47670,CVE-2022-49986,CVE-2022-50001,CVE-2022-50003,CVE-2022-50015,CVE-2022-50020,CVE-2022-50070,CVE-2022-50127,CVE-2022-50133,CVE-2022-50181,CVE-2022-50187,CVE-2022-50229,CVE-2024-53150,CVE-2025-21727,CVE-2025-22058,CVE-2025-37798,CVE-2025-37890,CVE-2025-37914,CVE-2025-38000,CVE-2025-38052,CVE-2025-38079,CVE-2025-38085,CVE-2025-38159,CVE-2025-38177,CVE-2025-38200,CVE-2025-38211,CVE-2025-38250,CVE-2025-38273,CVE-2025-38332,CVE-2025-38350,CVE-2025-38352,CVE-2025-38464,CVE-2025-38477") Plugin Feed: 202610181702
Version 1.3 Oct 18, 2026, 10:57 AM CVE (set "CVE" coverage to "CVE-2021-47103,CVE-2021-47670,CVE-2022-49986,CVE-2022-50001,CVE-2022-50003,CVE-2022-50015,CVE-2022-50020,CVE-2022-50070,CVE-2022-50127,CVE-2022-50133,CVE-2022-50181,CVE-2022-50187,CVE-2022-50229,CVE-2024-53150,CVE-2025-21727,CVE-2025-22058,CVE-2025-37890,CVE-2025-37914,CVE-2025-38000,CVE-2025-38052,CVE-2025-38079,CVE-2025-38085,CVE-2025-38159,CVE-2025-38177,CVE-2025-38200,CVE-2025-38211,CVE-2025-38250,CVE-2025-38273,CVE-2025-38332,CVE-2025-38350,CVE-2025-38352,CVE-2025-38464,CVE-2025-38477") Detection (updated detection logic) Exploit attributes ("Exploited by malware" changed from "True" to none) Plugin Feed: 202610181057
Version 1.2 Oct 2, 2026, 8:05 AM Exploit attributes ("Exploited by malware" set to "True") Plugin Feed: 202610020805
Version 1.1 Oct 1, 2026, 9:59 PM New Plugin Feed: 202610012159