CentOS Linux 8.5 主機安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1784274653 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：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)

  - 已解決 Linux 核心中的下列弱點：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)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2026：1784274653）

high Nessus Plugin ID 362361

版本 1.2

版本 1.1

版本 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
版本 1.1 Oct 1, 2026, 9:59 PM New Plugin Feed: 202610012159

偵測

CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點 （CENTOS8.5：CLSA-2026：1784274653）

high Nessus Plugin ID 362361

版本 1.2

版本 1.1

CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2026：1784274653）