Detections
Analytics
TencentOS Server 4: kernel (TSSA-2026:0409)
high Nessus Plugin ID 318181
Synopsis
The remote TencentOS Server 4 host is missing one or more security updates.Description
The version of Tencent Linux installed on the remote TencentOS Server 4 host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the TSSA-2026:0409 advisory.Package updates are available for TencentOS Server 4 that fix the following vulnerabilities:
CVE-2026-46300:
kernel: Fragnesia is a variant of Dirty Frag vulnerability in the ESP/XFRM leading to Local Privilege Escalation (LPE) vulnerability in the Linux kernel
CVE-2026-43503:
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false.
The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
CVE-2026-43494:
In the Linux kernel, the following vulnerability has been resolved:
net/rds: reset op_nents when zerocopy page pin fails
When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents.
Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again.
Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user().
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.
Solution
Update the affected packages.See Also
Plugin Details
Severity: High
ID: 318181
File Name: tencentos_TSSA_2026_0409.nasl
Version: 1.1
Type: Local
Family: Tencent Local Security Checks
Published: 6/2/2026
Updated: 6/2/2026
Supported Sensors: Nessus
Risk Information
VPR
Risk Factor: Critical
Score: 9.4
CVSS v2
Risk Factor: Medium
Base Score: 6.8
Temporal Score: 5.9
Vector: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS Score Source: CVE-2026-46300
CVSS v3
Risk Factor: High
Base Score: 7.8
Temporal Score: 7.5
Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Temporal Vector: CVSS:3.0/E:H/RL:O/RC:C
Vulnerability Information
CPE: p-cpe:/a:tencent:tencentos_server:kernel, cpe:/o:tencent:tencentos_server:4
Required KB Items: Host/local_checks_enabled, Host/cpu, Host/etc/os-release, Host/TencentOS/rpm-list
Exploit Available: true
Exploit Ease: Exploits are available
Patch Publication Date: 5/28/2026
Vulnerability Publication Date: 5/13/2026