TencentOS Server 2: kernel (TSSA-2026:0797)
| Reporter | Title | Published | Views | Family All 304 |
|---|---|---|---|---|
| CVE-64600-Refluxfs-POC | 27 Jul 202606:42 | – | githubexploit | |
| Exploit for CVE-2026-64600 | 28 Jul 202609:35 | – | githubexploit | |
| Exploit for CVE-2026-64600 | 26 Jul 202612:22 | – | githubexploit | |
| Exploit for CVE-2026-64600 | 24 Jul 202623:27 | – | githubexploit | |
| Exploit for CVE-2026-64600 | 28 Jul 202610:18 | – | githubexploit | |
| Exploit for CVE-2026-64600 | 23 Jul 202609:29 | – | githubexploit | |
| CVE-2026-64564 | 4 Aug 202606:23 | – | attackerkb | |
| CVE-2026-64600 | 23 Jul 202605:46 | – | attackerkb | |
| CVE-2026-43456 | 8 May 202614:22 | – | attackerkb | |
| CVE-2026-23451 | 3 Apr 202615:15 | – | attackerkb |
10
#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The descriptive text and package checks in this plugin were
# extracted from Tencent Linux Security Advisory TSSA-2026:0797.
##
include('compat.inc');
if (description)
{
script_id(333145);
script_version("1.1");
script_set_attribute(attribute:"plugin_modification_date", value:"2026/08/06");
script_cve_id(
"CVE-2026-23451",
"CVE-2026-31502",
"CVE-2026-43456",
"CVE-2026-64564",
"CVE-2026-64600"
);
script_name(english:"TencentOS Server 2: kernel (TSSA-2026:0797)");
script_set_attribute(attribute:"synopsis", value:
"The remote TencentOS Server 2 host is missing one or more security updates.");
script_set_attribute(attribute:"description", value:
"The version of Tencent Linux installed on the remote TencentOS Server 2 host is prior to tested version. It is,
therefore, affected by multiple vulnerabilities as referenced in the TSSA-2026:0797 advisory.
Package updates are available for TencentOS Server 2 that fix the following vulnerabilities:
CVE-2026-31502:
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-43456:
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix type confusion in bond_setup_by_slave()
kernel BUG at net/core/skbuff.c:2306!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306
RSP: 0018:ffffc90004aff760 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e
RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900
RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000
R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780
R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0
Call Trace:
<TASK>
ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900
dev_hard_header include/linux/netdevice.h:3439 [inline]
packet_snd net/packet/af_packet.c:3028 [inline]
packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0xa54/0xc30 net/socket.c:2592
___sys_sendmsg+0x190/0x1e0 net/socket.c:2646
__sys_sendmsg+0x170/0x220 net/socket.c:2678
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe1a0e6c1a9
When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,
bond_setup_by_slave() directly copies the slave's header_ops to the
bond device:
bond_dev->header_ops = slave_dev->header_ops;
This causes a type confusion when dev_hard_header() is later called
on the bond device. Functions like ipgre_header(), ip6gre_header(),all use
netdev_priv(dev) to access their device-specific private data. When
called with the bond device, netdev_priv() returns the bond's private
data (struct bonding) instead of the expected type (e.g. struct
ip_tunnel), leading to garbage values being read and kernel crashes.
Fix this by introducing bond_header_ops with wrapper functions that
delegate to the active slave's header_ops using the slave's own
device. This ensures netdev_priv() in the slave's header functions
always receives the correct device.
The fix is placed in the bonding driver rather than individual device
drivers, as the root cause is bond blindly inheriting header_ops from
the slave without considering that these callbacks expect a specific
netdev_priv() layout.
The type confusion can be observed by adding a printk in
ipgre_header() and running the following commands:
ip link add dummy0 type dummy
ip addr add 10.0.0.1/24 dev dummy0
ip link set dummy0 up
ip link add gre1 type gre local 10.0.0.1
ip link add bond1 type bond mode active-backup
ip link set gre1 master bond1
ip link set gre1 up
ip link set bond1 up
ip addr add fe80::1/64 dev bond1
CVE-2026-23451:
In the Linux kernel, the following vulnerability has been resolved:
team: fix header_ops type confusion with non-Ethernet ports
Similar to commit 950803f72547 (bonding: fix type confusion in
bond_setup_by_slave()) team has the same class of header_ops type
confusion.
For non-Ethernet ports, team_setup_by_port() copies port_dev->header_ops
directly. When the team device later calls dev_hard_header() or
dev_parse_header(), these callbacks can run with the team net_device
instead of the real lower device, so netdev_priv(dev) is interpreted as
the wrong private type and can crash.
The syzbot report shows a crash in bond_header_create(), but the root
cause is in team: the topology is gre -> bond -> team, and team calls
the inherited header_ops with its own net_device instead of the lower
device, so bond_header_create() receives a team device and interprets
netdev_priv() as bonding private data, causing a type confusion crash.
Fix this by introducing team header_ops wrappers for create/parse,
selecting a team port under RCU, and calling the lower device callbacks
with port->dev, so each callback always sees the correct net_device
context.
Also pass the selected lower device to the lower parse callback, so
recursion is bounded in stacked non-Ethernet topologies and parse
callbacks always run with the correct device context.
CVE-2026-64600:
In the Linux kernel, the following vulnerability has been resolved:
bonding: prevent potential infinite loop in bond_header_parse()
bond_header_parse() can loop if a stack of two bonding devices is setup,
because skb->dev always points to the hierarchy top.
Add new const struct net_device *dev parameter to
(struct header_ops)->parse() method to make sure the recursion
is bounded, and that the final leaf parse method is called.
CVE-2026-64564:
In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own
transport in DEL-IP processing. sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport. For an ASCONF located through its Address Parameter, that cached transport
corresponds to the Address Parameter, which need not be the packet's source address. A single ASCONF can
carry DEL-IP for the cached transport followed by a wildcard DEL-IP, causing use-after-free of the freed
transport.
Tenable has extracted the preceding description block directly from the Tencent Linux security advisory.
Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
script_set_attribute(attribute:"see_also", value:"https://mirrors.tencent.com/tlinux/errata/tssa-20260797.xml");
script_set_attribute(attribute:"solution", value:
"Update the affected packages.");
script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C");
script_set_cvss_temporal_vector("CVSS2#E:POC/RL:OF/RC:C");
script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
script_set_cvss3_temporal_vector("CVSS:3.0/E:P/RL:O/RC:C");
script_set_attribute(attribute:"cvss_score_source", value:"CVE-2026-64564");
script_set_attribute(attribute:"cvss3_score_source", value:"CVE-2026-64600");
script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available");
script_set_attribute(attribute:"exploit_available", value:"true");
script_set_attribute(attribute:"vuln_publication_date", value:"2026/04/03");
script_set_attribute(attribute:"patch_publication_date", value:"2026/08/04");
script_set_attribute(attribute:"plugin_publication_date", value:"2026/08/06");
script_set_attribute(attribute:"plugin_type", value:"local");
script_set_attribute(attribute:"cpe", value:"cpe:/o:tencent:tencentos_server:2");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:tencent:tencentos_server:kernel");
script_set_attribute(attribute:"generated_plugin", value:"current");
script_end_attributes();
script_category(ACT_GATHER_INFO);
script_family(english:"Tencent Local Security Checks");
script_copyright(english:"This script is Copyright (C) 2026 and is owned by Tenable, Inc. or an Affiliate thereof.");
script_dependencies("ssh_get_info2.nasl");
script_require_keys("Host/local_checks_enabled", "Host/etc/os-release", "Host/TencentOS/rpm-list", "Host/cpu");
exit(0);
}
include('rpm2.inc');
if (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var os_product = get_kb_item('installed_os/local/SSH/0/product');
if (isnull(os_product) || 'TencentOS' >!< os_product) audit(AUDIT_OS_NOT, 'TencentOS');
var os_version = get_kb_item('installed_os/local/SSH/0/version');
if (isnull(os_version)) audit(AUDIT_UNKNOWN_APP_VER, 'TencentOS');
if (! preg(pattern:"^2([^0-9]|$)", string:os_version)) audit(AUDIT_OS_NOT, 'TencentOS 2.x', 'TencentOS ' + os_version);
if (!get_kb_item('Host/TencentOS/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);
var cpu = get_kb_item('Host/cpu');
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ('x86_64' >!< cpu && cpu !~ "^i[3-6]86$" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'TencentOS', cpu);
var constraints = [
{
'release': '2',
'pkgs': [
{'reference':'bpftool-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-core-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-core-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-common-aarch64-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-common-x86_64-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-devel-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-devel-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-headers-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-headers-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-libs-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-libs-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-libs-devel-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-libs-devel-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'mlnx-ofed-dist-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'mlnx-ofed-dist-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'aarch64', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-debuginfo-5.4.119-19.0009.67.3.tl2', 'cpu':'x86_64', 'rpm_spec_vers_cmp':TRUE}
]
}
];
var os_release = get_one_kb_item('installed_os/local/SSH/0/release');
var os_sp = get_one_kb_item('Host/*/minor_release');
var flag = 0;
var reference;
var sp;
var _cpu;
var el_string;
var rpm_spec_vers_cmp;
var epoch;
var allowmaj;
var exists_check;
var cves;
foreach var constraint ( constraints ) {
# Check that the target release is equal to the affected release
if (!empty_or_null(constraint['release'])){
if (constraint['release'] != os_release) continue;
}
if (!empty_or_null(constraint['sp'])){
if (constraint['sp'] != os_sp) continue;
}
foreach var pkg ( constraint['pkgs'] ) {
reference = NULL;
sp = NULL;
_cpu = NULL;
el_string = NULL;
rpm_spec_vers_cmp = NULL;
epoch = NULL;
allowmaj = NULL;
exists_check = NULL;
cves = NULL;
if (!empty_or_null(pkg['reference'])) reference = pkg['reference'];
if (!empty_or_null(pkg['sp'])) sp = pkg['sp'];
if (!empty_or_null(pkg['cpu'])) _cpu = pkg['cpu'];
if (!empty_or_null(pkg['el_string'])) el_string = pkg['el_string'];
if (!empty_or_null(pkg['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = pkg['rpm_spec_vers_cmp'];
if (!empty_or_null(pkg['epoch'])) epoch = pkg['epoch'];
if (!empty_or_null(pkg['allowmaj'])) allowmaj = pkg['allowmaj'];
if (!empty_or_null(pkg['exists_check'])) exists_check = pkg['exists_check'];
if (!empty_or_null(pkg['cves'])) cves = pkg['cves'];
if (reference &&
## (no known rpm to check OR known rpm_exists)
(!exists_check || rpm_exists(rpm:exists_check)) &&
rpm_check(sp:sp, cpu:_cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj, cves:cves)) flag++;
}
}
if (flag)
{
security_report_v4(
port : 0,
severity : SECURITY_HOLE,
extra : rpm_report_get()
);
exit(0);
}
else
{
var tested = pkg_tests_get();
if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'bpftool / bpftool-debuginfo / kernel / etc');
}
Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation
06 Aug 2026 00:00Current
5.3Medium risk
Vulners AI Score5.3
CVSS 3.17.8
EPSS0.00507