製品・ソフトウェアに関する情報
LinuxのLinux Kernelにおける不特定の脆弱性
Title LinuxのLinux Kernelにおける不特定の脆弱性
Summary

Linuxカーネルにおいて、以下の脆弱性が修正されました。この脆弱性は、net: skbuffのフラグメント転送ヘルパーを通じて共有フラグメントマーカーが正しく伝播されない問題に起因します。2つのフラグメント転送ヘルパー(__pskb_copy_fclone() と skb_shift())は、フラグメントをソースから宛先に移動するときに skb_shinfo()-flags の SKBFL_SHARED_FRAG ビットを伝播しません。__pskb_copy_fclone() はフラグメント記述子のコピー後に残りの shinfo メタデータを skb_copy_header() に委ねますが、このヘルパーは gso_{size,segs,type} のみを引き継ぎ、skb_shinfo()-flags に触れません。skb_shift() はフラグメント記述子を直接移動し、flags はそのままにします。その結果、宛先の skb は同じ外部所有またはページキャッシュ対応ページへの参照を維持しつつ、skb_has_shared_frag() が false を返します。この不整合は、skb_has_shared_frag() を使って共有ページを skb_cow_data() 経由で迂回する必要があるかを判断するインプレースライターにとって有害です。ESP入力(esp4.c, esp6.c)はそのようなライターの一例であり、単一の nft 'dup to local' ルールやその他の nf_dup_ipv4() / xt_TEE 呼び出しで pskb_copy() された skb が esp_input() にてマーカーを剥奪された状態で渡ると、権限のないユーザーが authencesn-ESN の逸脱書き込みを介してルート所有の読み取り専用ファイルのページキャッシュに書き込むことが可能になります。フラグメント記述子が実際にソースから移動された場合は、宛先の skb に SKBFL_SHARED_FRAG を設定します。skb_copy() と skb_copy_expand() も skb_copy_header() を共有しますが、すべてのページデータを新たに割り当てられたヘッドストレージに線形化し、nr_frags == 0 となるため、skb_has_shared_frag() は自動的に false を返しており、変更は不要です。同様の欠落は skb_gro_receive() と skb_gro_receive_list() にも存在します。前者は直接のフラグメント移動ループおよび head_frag + memcpy 経路の2つで受信skbのフラグメント記述子をアキュムレーターの最後のサブskbに移動し、後者は受信skbを p の frag_list に連結します。下流の skb_segment() は skb_shinfo(p)-flags のみを読み取り、skb_segment_list() は各サブskbの shinfo を nskb として再利用するため、p と lp は両方マーカーを持つ必要があります。同様の欠落は tcp_clone_payload() にも存在します。これは sk_write_queue 上の skb からフラグメント記述子を移動して新たに割り当てられた nskb で MTU プローブ skb を構築します。このヘルパーは同じタイプに属しており、一貫性のため同じ修正が必要です。現在のところ、このギャップを介してユーザーページに到達する TCP TX 側のインプレースライターは知られていませんが、将来マーカーに依存する利用者が silently 後退する可能性があります。同様の欠落は skb_segment() にもあります。反復ごとのフラグマージは head_skb のフラグのみを取得し、head_skb のフラグメント枯渇時に frag_skb を list_skb に再バインドする内部のスイッチは新しい frag_skb のフラグを nskb に反映しません。両方の箇所で frag_skb のフラグを反映させ、frag_list メンバーからフラグメントを取り出すセグメントがマーカーを保持するように修正しました。

Possible impacts ・当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。 ・当該ソフトウェアが扱う全ての情報が書き換えられる可能性があります。 ・当該ソフトウェアが完全に停止する可能性があります。 
Solution

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

Publication Date May 23, 2026, midnight
Registration Date June 29, 2026, 11:18 a.m.
Last Update June 29, 2026, 11:18 a.m.
CVSS3.0 : 重要
Score 8.8
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Affected System
Linux
Linux Kernel 3.9 以上 5.10.257 未満
Linux Kernel 5.11 以上 5.15.208 未満
Linux Kernel 5.16 以上 6.1.174 未満
Linux Kernel 6.13 以上 6.18.33 未満
Linux Kernel 6.19 以上 7.0.10 未満
Linux Kernel 6.2 以上 6.6.141 未満
Linux Kernel 6.7 以上 6.12.91 未満
Linux Kernel 7.1
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年06月29日]
  掲載
June 29, 2026, 11:18 a.m.

NVD Vulnerability Information
CVE-2026-43503
Summary

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.

Publication Date May 23, 2026, 9:17 p.m.
Registration Date May 27, 2026, 4:06 a.m.
Last Update May 30, 2026, 8:17 p.m.
Related information, measures and tools
Common Vulnerabilities List