AS-2026-017: Linux Kernel (GhostLock, DirtyClone)

2026-08-03

---

Statement

A Linux kernel local privilege escalation vulnerability, named "GhostLock" (with CVE-2026-43499), has been identified in the Linux kernel's rtmutex / futex locking subsystem. If the vulnerability is exploited, it allows a local authenticated attacker to escalate privileges on affected Linux system.

A variant of recently disclosed Dirty Frag, namely "DirtyClone" (with CVE-2026-43503), has been identified in the Linux kernel's networking stack, specifically in socket buffer (sk_buff) fragment handling. The vulnerability could allow a local unprivileged attacker to corrupt page-cache-backed memory and obtain root-level privileges on affected Linux systems.

• CVE-2026-43499 affects certain ASUSTOR products that have Linux kernel versions higher than 2.6.39 and ADM versions ranging from 4.1 to 5.1. Updates with Linux Kernel Patch will be released as soon as possible.
• CVE-2026-43503 affects certain ASUSTOR products that have Linux kernel versions higher than 4.11 and ADM versions ranging from 4.1 to 5.1. Updates with Linux Kernel Patch will be released as soon as possible.
• Linux Kernel Patch has been updated on ADM 5.1.4.RJV2 to resolve the issues.

Affected Products

Product	Severity	Fixed Release Availability
ADM 5.0 and 5.1	Moderate	Upgrade to ADM 5.1.4.RJV2 or above.
ADM 4.3, 4.2 and 4.1	Moderate	Ongoing.

NOT affected NAS models with CVE-2026-43503:

• Drivestor (AS1102T, AS1104T)
• Drivestor Pro (AS3302T, AS3304T)
• AS4002T, AS4004T

Detail

• CVE-2026-43499
  • Severity: High
  • CVSS3.1 Base Score: 7.8
  • CVSS3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]
• CVE-2026-43503
  • Severity: High
  • CVSS3.1 Base Score: 8.8
  • CVSS3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
  • 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 ' 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.

Reference

• CVE-2026-43499
• CVE-2026-43503

Revision

Revision	Date	Description
1	2026-07-20	Initial public release.
2	2026-08-03	ADM 5.1.4.RJV2 have been released for fixing the issues.