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

  - In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in     macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2     ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0     link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add     00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is     triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or     MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called     from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case     macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a     reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv     data of the link that is being created. When register_netdevice() fails, the error is returned from     macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ms, extack);
    else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is     called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached     to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac     address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is     to make sure we call macvlan_flush_sources() regardless of @create value whenever goto     destroy_macvlan_port; path is taken. Many thanks to valis for following up on this issue.
    (CVE-2026-23209)

  - In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping     after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork     mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction,     which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow     fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping     beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the     wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio     write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence     counter changes across the ILOCK cycle. (CVE-2026-64600)

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-2026:1784274653)

high Nessus Plugin ID 362361

Version 1.2

Version 1.1

Version 1.2 Oct 18, 2026, 10:57 AM CVE (set "CVE" coverage to "CVE-2026-23209,CVE-2026-64600") CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:POC/RL:OF/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:P/RL:O/RC:C") Detection (updated detection logic) Exploit attributes ("Exploit available" set to "True") Exploit attributes ("Exploitability ease" changed from "No known exploits are available" to "Exploits are available") Plugin metadata Plugin Feed: 202610181057
Version 1.1 Oct 1, 2026, 9:59 PM New Plugin Feed: 202610012159