Detections
Analytics
Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1778930898)
high Nessus Plugin ID 351584
Language:
Synopsis
The Rocky Linux host is missing one or more security updates.Description
The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1778930898 advisory.- 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-43503)
- In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer.
But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS).
Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional drop capabilities model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached last dumpability flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override. (CVE-2026-46333)
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 based on the guidance in TuxCare advisory ALMALINUX9.6:CLSA-2026:1778930898.See Also
Plugin Details
Severity: High
ID: 351584
File Name: tuxcare_rocky_linux_9.6_CLSA-2026-1778930898.nasl
Version: 1.4
Type: Local
Published: 9/30/2026
Updated: 10/21/2026
Supported Sensors: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
Risk Information
VPR
Risk Factor: Critical
Score: 9.2
Percentile: 99.77
Vendor
Vendor Severity: Important
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-46333
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
Required KB Items: Host/local_checks_enabled, Host/cpu, Host/RockyLinux/release, Host/RockyLinux/rpm-list, Host/OS/extended-third-party
Exploit Available: true
Exploit Ease: Exploits are available
Patch Publication Date: 5/16/2026
Vulnerability Publication Date: 5/15/2026
Reference Information
CVE: CVE-2026-43503, CVE-2026-46333
CLSA: 2026:1778930898