GHSA-494P-Q444-9XF7

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-07-02 12:30
VLAI
Details

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.

Severity
8.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-43503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-664"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-23T12:17:02Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: propagate shared-frag marker through frag-transfer helpers\n\nTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail\nto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()-\u003eflags when\nmoving frags from source to destination.  __pskb_copy_fclone() defers\nthe rest of the shinfo metadata to skb_copy_header() after copying\nfrag descriptors, but that helper only carries over gso_{size,segs,\ntype} and never touches skb_shinfo()-\u003eflags; skb_shift() moves frag\ndescriptors directly and leaves flags untouched.  As a result, the\ndestination skb keeps a reference to the same externally-owned or\npage-cache-backed pages while reporting skb_has_shared_frag() as\nfalse.\n\nThe mismatch is harmful in any in-place writer that uses\nskb_has_shared_frag() to decide whether shared pages must be detoured\nthrough skb_cow_data().  ESP input is one such writer (esp4.c,\nesp6.c), and a single nft \u0027dup to \u003clocal\u003e\u0027 rule -- or any other\nnf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()\u0027d\nskb in esp_input() with the marker stripped, letting an unprivileged\nuser write into the page cache of a root-owned read-only file via\nauthencesn-ESN stray writes.\n\nSet SKBFL_SHARED_FRAG on the destination whenever frag descriptors\nwere actually moved from the source.  skb_copy() and skb_copy_expand()\nshare skb_copy_header() too but linearize all paged data into freshly\nallocated head storage and emerge with nr_frags == 0, so\nskb_has_shared_frag() returns false on its own; they need no change.\n\nThe same omission exists in skb_gro_receive() and skb_gro_receive_list().\nThe former moves the incoming skb\u0027s frag descriptors into the\naccumulator\u0027s last sub-skb via two paths (a direct frag-move loop and\nthe head_frag + memcpy path); the latter chains the incoming skb whole\nonto p\u0027s frag_list.  Downstream skb_segment() reads only\nskb_shinfo(p)-\u003eflags, and skb_segment_list() reuses each sub-skb\u0027s\nshinfo as the nskb -- both p and lp must carry the marker.\n\nThe same omission also exists in tcp_clone_payload(), which builds an\nMTU probe skb by moving frag descriptors from skbs on sk_write_queue\ninto a freshly allocated nskb.  The helper falls into the same family\nand warrants the same fix for consistency; no TCP TX-side in-place\nwriter is currently known to reach a user page through this gap, but\na future consumer depending on the marker would regress silently.\n\nThe same omission exists in skb_segment(): the per-iteration flag\nmerge takes only head_skb\u0027s flag, and the inner switch that rebinds\nfrag_skb to list_skb on head_skb-frags exhaustion does not fold the\nnew frag_skb\u0027s flag into nskb.  Fold frag_skb\u0027s flag at both sites\nso segments drawing frags from frag_list members carry the marker.",
  "id": "GHSA-494p-q444-9xf7",
  "modified": "2026-07-02T12:30:48Z",
  "published": "2026-05-26T13:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43503"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23240"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23245"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23468"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23469"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23470"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23471"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24814"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:25044"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:33486"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-43503"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480902"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/48f6a5356a33dd78e7144ae1faef95ffc990aae0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43503.json"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19521"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19540"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19568"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19569"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19664"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19666"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19705"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19711"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19875"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20051"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20054"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20087"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20129"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20130"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20299"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20593"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21656"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21690"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21695"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:21702"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23233"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.