Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - net：一律剖析 __virtio_net_hdr_to_skb（） 中的 GSO 封包 Commit 9e8db5913264 （net：避免不受信任的 GSO 驗證中的誤報） 在 __virtio_net_hdr_to_skb（） 中不VIRTIO_NET_HDR_F_NEEDS_CSUM 的 GSO 封包進行流量剖析之前，新增了「& skb->network_header」檢查，因為某些調用端 （例如 tun_get_user（）、tun_xdp_one（） virtnet_receive_done（） 和 raw_verify_header（）） 在初始化 skb->network_header 和 skb->dev 之前呼叫 virtio_net_hdr_*_to_skb（）。因為 __alloc_skb（） 和
    __build_skb_around（） 將 skb->network_header 零初始化為 0（與初始化為 ~0U 的 mac_header 和 transport_header 不同），這四個調用方始終具有 skb->network_header == 0 並在 __virtio_net_hdr_to_skb（） 中繞過流剖析。更一般地說，skb->network_header 是 skb->head 的偏移量 （其中，只要 skb_headroom（skb） 為 0,0 也是有效的偏移量），而不是布林旗標。每當跳過 'if （gso_type &; skb->network_header）' 分支時，後援 'else if （gso_type）' 只會拉取 nh_min_len + thlen （TCPv4 為 40 位元組），而沒有剖析封包，沒有驗證ip_proto或n_proto，也沒有設定 skb->transport_header。如果封包具有格式錯誤的網路標頭，則不會被拒絕，後續的 skb_probe_transport_header（） 也會失敗，使 skb->transport_header 處於 ~0U （0xffff）。同樣地，如果 IPv4 封包攜帶 IP 選項 （ihl > 5） 或 IPv6 封包攜帶擴充標頭，則僅提取 nh_min_len + thlen 可能會將 TCP 標頭留在 skb->head 之外。在這兩種情況下，skb_gso_transport_seglen（） 中的 tcp_hdrlen（skb） 都會越界讀取： 錯誤：KASAN：skb_gso_transport_seglen 中的 slab-out-of-bounds 依任務 poc/133 讀取大小 2 skb_gso_transport_seglen （net/core/gso.c：155） skb_gso_validate_mac_len （net/core/gso.c：270） tbf_enqueue （net/sched/sch_tbf.c：260） dev_qdisc_enqueue （net/core/dev.c：4227） __dev_queue_xmit （net/core/dev.c：4884） 此外， 在流量剖析之前，僅在「if（！skb->protocol）」內檢查 virtio_net_hdr_match_proto（），當調用方預先設定 skb->protocol 時，會跳過驗證，並拒絕外部 L2 通訊協定為 ETH_P_8021Q 或 ETH_P_8021AD 的 VLAN 標記框架。透過以下方式解決此問題： 1. 在 tun_get_user（）、tun_xdp_one（）、virtnet_receive_done（） 和 raw_verify_header（） 中virtio_net_hdr_*_to_skb（）之前初始化 skb->dev 和 skb->network_header（加上 skb->protocol for IFF_TUN）。在 tun_get_user（） 中，刪除IFF_TUN情況下的冗餘 skb_reset_mac_header（skb），因為 __virtio_net_hdr_to_skb（） 會無條件重設mac_header。2. 移除 '&; skb->network_header' 和 'else if （gso_type）' 後援
    __virtio_net_hdr_to_skb（），因此所有沒有VIRTIO_NET_HDR_F_NEEDS_CSUM的 GSO 封包都會進行流量剖析，將其傳輸標頭提取到線性資料中，並設定 skb->transport_header。3. 將 virtio_net_hdr_match_proto（） 檢查移至 skb_flow_dissect_flow_keys_basic（） 之後，根據hdr_gso_type驗證keys.basic.n_proto。（CVE-2026-98954）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - net：始终分析 __virtio_net_hdr_to_skb（） 中的 GSO 数据包 提交 9e8db5913264（net：避免不受信任的 GSO 验证中的误报） 在不VIRTIO_NET_HDR_F_NEEDS_CSUM __virtio_net_hdr_to_skb（） 中对 GSO 数据包进行流量分析之前添加了“&; skb->network_header”检查，因为某些调用程序（例如 tun_get_user（）、tun_xdp_one（）、 virtnet_receive_done（） 和 raw_verify_header（）） 在初始化 skb->network_header 和 skb->dev 之前调用 virtio_net_hdr_*_to_skb（）。因为 __alloc_skb（） 和
    __build_skb_around（） 零初始化 skb->network_header 为 0（与初始化为 ~0U 的 mac_header 和 transport_header 不同），这四个调用程序始终具有 skb->network_header == 0 并绕过了 __virtio_net_hdr_to_skb（） 中的流分析。更一般地说，skb->network_header 是 skb->head 的偏移（其中 skb_headroom（skb） 为 0 时，0 也是有效的偏移），而不是布尔标记。每当跳过“if （gso_type &&; skb->network_header）”分支时，回退“else if （gso_type）”仅提取 nh_min_len + thlen（TCPv4 为 40 字节），而不分析数据包、未验证ip_proto或n_proto并且未设置 skb->transport_header。如果数据包具有畸形网络标头，则不会被拒绝，后续的 skb_probe_transport_header（） 也会失败，从而使 skb->transport_header 处于 ~0U （0xffff）。同样，如果 IPv4 数据包携带 IP 选项 （ihl > 5） 或 IPv6 数据包携带扩展标头，则仅拉取 nh_min_len + thlen 可将 TCP 标头留在 skb->head 之外。在两种情况下，skb_gso_transport_seglen（） 中的 tcp_hdrlen（skb） 都会读取越界：缺陷：KASAN：按任务 poc/133 读取的大小为 2 的 skb_gso_transport_seglen 中的 slab-out-of-bound skb_gso_transport_seglen （net/core/gso.c：155） skb_gso_validate_mac_len （net/core/gso.c：270） tbf_enqueue （net/sched/sch_tbf.c：260） dev_qdisc_enqueue （net/core/dev.c：4227） __dev_queue_xmit （net/core/dev.c：4884） 此外， 在流解析之前，仅在“if （！skb->protocol）”内部检查 virtio_net_hdr_match_proto（），在调用程序预设 skb->protocol 时跳过验证并拒绝外部 L2 协议为 ETH_P_8021Q 或ETH_P_8021AD的 VLAN 标签帧。通过以下方式修复此问题：1. 在 tun_get_user>）、tun_xdp_one（）、virtnet_receive_done（） 和 raw_verify_header（） 中 virtio_net_hdr_*_to_skb（） 之前初始化 skb-dev 和 skb->network_header（加上用于 IFF_TUN 的 skb->protocol）。在 tun_get_user（） 中，在IFF_TUN情况下删除冗余skb_reset_mac_header （skb），因为 __virtio_net_hdr_to_skb（） 会无条件重置mac_header。2. 删除 '&; skb->network_header' 和未经验证的'else if （gso_type）'回退
    __virtio_net_hdr_to_skb（），以便对所有没有VIRTIO_NET_HDR_F_NEEDS_CSUM的 GSO 数据包进行流分析，将其传输标头拉入线性数据，并设置 skb->transport_header。3. 将 virtio_net_hdr_match_proto（） 检查移到 skb_flow_dissect_flow_keys_basic（） 之后，验证keys.basic.n_proto是否符合hdr_gso_type。（CVE-2026-98954）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - net:__virtio_net_hdr_to_skb() コミット 9e8db5913264(net:信頼できない GSO 検証での偽陽性を回避)で、__virtio_net_hdr_to_skb() で VIRTIO_NET_HDR_F_NEEDS_CSUM なしで GSO パケットをフローで分析する前に「& skb->network_header」チェックを追加しました。これは、一部の呼び出し元(tun_get_user()、tun_xdp_one() など)、 virtnet_receive_done() および raw_verify_header()) は、skb->network_header と skb->dev を初期化する前に virtio_net_hdr_*_to_skb() を呼び出しました。__alloc_skb() と
    __build_skb_around() skb->network_header を 0 にゼロ初期化します(~0U に初期化される mac_header や transport_header とは異なり)、これら 4 つの呼び出し元は常に skb->network_header == 0 であり、__virtio_net_hdr_to_skb() でフローディセクションをバイパスしていました。より一般的には、skb->network_header は skb->head からのオフセットです (0 は skb_headroom(skb) が 0 の場合は常に有効なオフセットでもあります) であり、ブールフラグではありません。「if (gso_type &; skb->network_header)」ブランチがスキップされるたびに、フォールバックの「else if (gso_type)」は、パケットを解析せず、ip_proto または n_proto を検証せず、skb->transport_header を設定することなく、nh_min_len + thlen(TCPv4 の場合は 40 バイト)のみをプルしました。パケットに無効な形式のネットワークヘッダーがある場合、パケットは拒否されず、後続の skb_probe_transport_header() も失敗し、skb->transport_header を ~0U(0xffff)に残します。同様に、IPv4 パケットが IP オプション(ihl > 5)を運ぶか、IPv6 パケットが拡張ヘッダーを運ぶ場合、nh_min_len + thlen のみをプルすることで、TCP ヘッダーを skb->head の外に残すことができます。どちらの場合も、skb_gso_transport_seglen()のtcp_hdrlen(skb)は領域外読み取りを行います。バグ:KASAN:タスクpoc/133 skb_gso_transport_seglenによるサイズ2の読み取りのskb_gso_transport_seglenのslab-out-of-bounds(net/core/gso.c:155)skb_gso_validate_mac_len(net/core/gso.c:270)tbf_enqueue(net/sched/sch_tbf.c:260)dev_qdisc_enqueue(net/core/dev.c:4227)__dev_queue_xmit(net/core/dev.c:4884)さらに、 フローディセクタの前に「if(!skb->protocol)」内でのみ virtio_net_hdr_match_proto() をチェックしていると、skb->protocol が呼び出し側によって事前設定されている場合は検証がスキップされ、外側の L2 プロトコルが ETH_P_8021Q または ETH_P_8021AD である VLAN タグ付きフレームが拒否されます。この問題を修正します。1. tun_get_user()、tun_xdp_one()、virtnet_receive_done()、raw_verify_header() の virtio_net_hdr_*_to_skb() より前の skb->dev および skb->network_header(および IFF_TUN の場合は skb->protocol )を初期化します。tun_get_user() の場合、__virtio_net_hdr_to_skb() は無条件にmac_headerをリセットするため、IFF_TUNの場合では冗長な skb_reset_mac_header(skb) をドロップします。2. での「&; skb->network_header」および検証されない「else if (gso_type)」フォールバックを削除
    __virtio_net_hdr_to_skb() したがって、VIRTIO_NET_HDR_F_NEEDS_CSUMのないすべての GSO パケットはフロー分析され、トランスポートヘッダーが線形データに引き込まれ、skb->transport_header が設定されます。3. virtio_net_hdr_match_proto() チェックを skb_flow_dissect_flow_keys_basic() の後に移動し、hdr_gso_typeに対するkeys.basic.n_protoを検証します。(CVE-2026-98954)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - net: always dissect GSO packets in __virtio_net_hdr_to_skb() Commit 9e8db5913264 (net: avoid false     positives in untrusted gso validation) added a '&& skb->network_header' check before flow-dissecting GSO     packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in __virtio_net_hdr_to_skb(), because some callers (such as     tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called     virtio_net_hdr_*_to_skb() before initializing skb->network_header and skb->dev. Because __alloc_skb() and
    __build_skb_around() zero-initialize skb->network_header to 0 (unlike mac_header and transport_header     which are initialized to ~0U), those four callers always had skb->network_header == 0 and bypassed flow     dissection in __virtio_net_hdr_to_skb(). More generally, skb->network_header is an offset from skb->head     (where 0 is also a valid offset whenever skb_headroom(skb) is 0), not a boolean flag. Whenever the 'if     (gso_type && skb->network_header)' branch was skipped, the fallback 'else if (gso_type)' only pulled     nh_min_len + thlen (40 bytes for TCPv4) without dissecting the packet, without validating ip_proto or     n_proto, and without setting skb->transport_header. If the packet has a malformed network header, it is     not rejected and a subsequent skb_probe_transport_header() also fails, leaving skb->transport_header at     ~0U (0xffff). Similarly, if an IPv4 packet carries IP options (ihl > 5) or an IPv6 packet carries     extension headers, pulling only nh_min_len + thlen can leave the TCP header outside skb->head. In both     cases, tcp_hdrlen(skb) in skb_gso_transport_seglen() reads out-of-bounds: BUG: KASAN: slab-out-of-bounds     in skb_gso_transport_seglen Read of size 2 by task poc/133 skb_gso_transport_seglen (net/core/gso.c:155)     skb_gso_validate_mac_len (net/core/gso.c:270) tbf_enqueue (net/sched/sch_tbf.c:260) dev_qdisc_enqueue     (net/core/dev.c:4227) __dev_queue_xmit (net/core/dev.c:4884) In addition, checking     virtio_net_hdr_match_proto() only inside 'if (!skb->protocol)' before flow dissection both skipped     validation when skb->protocol was pre-set by the caller and rejected VLAN-tagged frames whose outer L2     protocol is ETH_P_8021Q or ETH_P_8021AD. Fix this by: 1. Initializing skb->dev and skb->network_header     (plus skb->protocol for IFF_TUN) before virtio_net_hdr_*_to_skb() in tun_get_user(), tun_xdp_one(),     virtnet_receive_done(), and raw_verify_header(). In tun_get_user(), drop the redundant     skb_reset_mac_header(skb) in the IFF_TUN case since __virtio_net_hdr_to_skb() unconditionally resets     mac_header. 2. Removing '&& skb->network_header' and the unvalidated 'else if (gso_type)' fallback in
    __virtio_net_hdr_to_skb() so all GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are flow-dissected, have     their transport header pulled into linear data, and have skb->transport_header set. 3. Moving the     virtio_net_hdr_match_proto() check to after skb_flow_dissect_flow_keys_basic(), validating     keys.basic.n_proto against hdr_gso_type. (CVE-2026-98954)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
371511	Linux Distros 未修補弱點：CVE-2026-98954	Nessus	Misc.	10/23/2026	10/27/2026	medium
371511	Linux Distros 未修补的漏洞：CVE-2026-98954	Nessus	Misc.	10/23/2026	10/27/2026	medium
371511	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98954	Nessus	Misc.	10/23/2026	10/27/2026	medium
371511	Linux Distros Unpatched Vulnerability : CVE-2026-98954	Nessus	Misc.	10/23/2026	10/27/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium