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

  - fastd 是 VPN 程序，可透過 UDP 建立 IP 封包和乙太網路框架通道。當接收來自未知 IP 位址/連接埠組合的資料封包時，fastd 會假設其中一個已連線的對等端已移至新位址，並透過傳送交握封包來起始重新連線。此快速重新連線可避免在建立新連線之前等待工作階段逾時 (最多 ~90 秒)。即使是只包含 fastd 封包類型標頭的 1 位元組 UDP 封包，也可觸發更大的交握封包 (~150 位元組的 UDP 承載)。包含 IPv4 和 UDP 標頭在內，產生的放大係數大約為 12-13。透過將具有偽造來源位址的資料封包傳送至可在網際網路上連線的 fastd 執行個體，此 UDP 流量放大可用來發動分散式拒絕服務攻擊。此弱點已在 v23 中修正。 (CVE-2025-24356)

請注意，Nessus 依賴供應商報告的套件存在。

The remote Fedora 41 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2025-b895b18cfe advisory.


    This release contains a number of small improvements and bugfixes, including mitigations for the LOW     severity vulnerability `CVE-2025-24356`.

    ## Bugfixes

    -   Add mitigations for fast-reconnect amplification attacks

        When receiving a data packet from an unknown IP address/port combination, fastd will assume that one     of its connected peers has moved to a new address (for example due to internet lines with dynamic IP, or     roaming between WWAN and a local internet connection) and initiate a reconnect by sending a handshake     packet. This fast reconnect avoids having to wait for a session timeout (up to ~90s) until a new     connection is established.

        Even a 1-byte UDP packet just containing the fastd packet type header can trigger a much larger     handshake packet (~150 bytes of UDP payload). With fastd v22, this number is doubled, because two     handshakes are sent (one in a pre-v22-compatible format and one in a new L2TP-style format). Including     IPv4 and UDP headers, the resulting amplification factor is roughly 12-13.

        By sending data packets with a spoofed source address to fastd instances reachable on the internet,     this amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack.

        fastd has always implemented rate limiting for handshakes to unknown IP addresses and ports to 1     handshake per 15s to avoid this kind of attack, however the rate is limited per-port and not per-address,     thus still allowing handshakes to be sent to all 65535 UDP ports of the same IP address unlimited.

        The issue has been mitigated in fastd v23 by a number of changes:

        -   Rate-limiting has been changed changed to be applied per-address instead of per-port

        -   Only one handshake instead of two handshakes is sent for fast-reconnect (by determining from the     format of the data packet whether a pre-v22 or L2TP-style handshake should be used)

        -   Require at least a full method header instead of just a single byte for a data packet to be     considered valid. This does not have an effect on instances that enable the `null` method (regardless of     `null` being actually in use), as a single-byte UDP packet is a valid `null` keepalive, but for all other     methods the amplification factor is slightly reduced.


        Only fastd instances that allow connections from arbitrary IP addresses are vulnerable. Instances in a     client role that configure their peers using the `remote` config option (which includes the common     deployment as part of the [Gluon](https://github.com/freifunk-gluon/gluon) wireless mesh firmware) will     not respond to unexpected data packets with a handshake and are therefore unaffected.

        `CVE-2025-24356` has been assigned to this issue. The severity of this vulnerability is considered     LOW.

        A GitHub security advisory can be found under [GHSA-pggg-     vpfv-4rcv](https://github.com/neocturne/fastd/security/advisories/GHSA-pggg-vpfv-4rcv).

    -   Fix config loading to fail on `offload l2tp no;` when L2TP offloading is unsupported by the fastd     build or the kernel

    -   Fix assembly Salsa20(/12) implementations accidentally generating the Linux- specific `.note.GNU-     stack` ELF section on non-Linux systems

        This is unlikely to have caused any issues, as other systems should just ignore the unknown section.

    -   Status socket: - Fix interface name information with L2TP offloading - Add per-peer MTU information

    -   Documentation: - Fix incorrect persist interface examples - Improve explanation of `float`     option

    -   Build: - Fix build on macOS (again) - Fix build with Meson 0.49 (the minimum version marked as     supported by fastd)


    ## Other changes

    -   Add support for Indirect Branch Tracking and Shadow Stacks on x86

        The assembly Salsa20(/12) implementations have been marked compatible with IBT and SHSTK, which are     part of Intel CET (Control-flow Enforcement Technology) and can be enabled using the `-fcf-protection` GCC     option.

    -   The file `COPYRIGHT` has been renamed to `LICENSE`

    -   The vendored version of libmnl that is used with `libmnl_builtin=true` has been updated to 1.0.5



Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Fedora 40 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2025-29fc4fefd5 advisory.


    This release contains a number of small improvements and bugfixes, including mitigations for the LOW     severity vulnerability `CVE-2025-24356`.

    ## Bugfixes

    -   Add mitigations for fast-reconnect amplification attacks

        When receiving a data packet from an unknown IP address/port combination, fastd will assume that one     of its connected peers has moved to a new address (for example due to internet lines with dynamic IP, or     roaming between WWAN and a local internet connection) and initiate a reconnect by sending a handshake     packet. This fast reconnect avoids having to wait for a session timeout (up to ~90s) until a new     connection is established.

        Even a 1-byte UDP packet just containing the fastd packet type header can trigger a much larger     handshake packet (~150 bytes of UDP payload). With fastd v22, this number is doubled, because two     handshakes are sent (one in a pre-v22-compatible format and one in a new L2TP-style format). Including     IPv4 and UDP headers, the resulting amplification factor is roughly 12-13.

        By sending data packets with a spoofed source address to fastd instances reachable on the internet,     this amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack.

        fastd has always implemented rate limiting for handshakes to unknown IP addresses and ports to 1     handshake per 15s to avoid this kind of attack, however the rate is limited per-port and not per-address,     thus still allowing handshakes to be sent to all 65535 UDP ports of the same IP address unlimited.

        The issue has been mitigated in fastd v23 by a number of changes:

        -   Rate-limiting has been changed changed to be applied per-address instead of per-port

        -   Only one handshake instead of two handshakes is sent for fast-reconnect (by determining from the     format of the data packet whether a pre-v22 or L2TP-style handshake should be used)

        -   Require at least a full method header instead of just a single byte for a data packet to be     considered valid. This does not have an effect on instances that enable the `null` method (regardless of     `null` being actually in use), as a single-byte UDP packet is a valid `null` keepalive, but for all other     methods the amplification factor is slightly reduced.


        Only fastd instances that allow connections from arbitrary IP addresses are vulnerable. Instances in a     client role that configure their peers using the `remote` config option (which includes the common     deployment as part of the [Gluon](https://github.com/freifunk-gluon/gluon) wireless mesh firmware) will     not respond to unexpected data packets with a handshake and are therefore unaffected.

        `CVE-2025-24356` has been assigned to this issue. The severity of this vulnerability is considered     LOW.

        A GitHub security advisory can be found under [GHSA-pggg-     vpfv-4rcv](https://github.com/neocturne/fastd/security/advisories/GHSA-pggg-vpfv-4rcv).

    -   Fix config loading to fail on `offload l2tp no;` when L2TP offloading is unsupported by the fastd     build or the kernel

    -   Fix assembly Salsa20(/12) implementations accidentally generating the Linux- specific `.note.GNU-     stack` ELF section on non-Linux systems

        This is unlikely to have caused any issues, as other systems should just ignore the unknown section.

    -   Status socket: - Fix interface name information with L2TP offloading - Add per-peer MTU information

    -   Documentation: - Fix incorrect persist interface examples - Improve explanation of `float`     option

    -   Build: - Fix build on macOS (again) - Fix build with Meson 0.49 (the minimum version marked as     supported by fastd)


    ## Other changes

    -   Add support for Indirect Branch Tracking and Shadow Stacks on x86

        The assembly Salsa20(/12) implementations have been marked compatible with IBT and SHSTK, which are     part of Intel CET (Control-flow Enforcement Technology) and can be enabled using the `-fcf-protection` GCC     option.

    -   The file `COPYRIGHT` has been renamed to `LICENSE`

    -   The vendored version of libmnl that is used with `libmnl_builtin=true` has been updated to 1.0.5



Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

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

  - fastd is a VPN daemon which tunnels IP packets and Ethernet frames over UDP. When receiving a data packet     from an unknown IP address/port combination, fastd will assume that one of its connected peers has moved     to a new address and initiate a reconnect by sending a handshake packet. This fast reconnect avoids     having to wait for a session timeout (up to ~90s) until a new connection is established. Even a 1-byte UDP     packet just containing the fastd packet type header can trigger a much larger handshake packet (~150 bytes     of UDP payload). Including IPv4 and UDP headers, the resulting amplification factor is roughly 12-13. By     sending data packets with a spoofed source address to fastd instances reachable on the internet, this     amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack. This     vulnerability is fixed in v23. (CVE-2025-24356)

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

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

  - fastd 是通过 UDP 传送 IP 数据包和以太网帧的 VPN 后台程序。从未知 IP 地址/端口组合收到数据包时，fastd 将假设其连接的一个对等机已移动至新地址，并通过发送握手数据包发起重新连接。这种快速重新连接避免了在建立新连接之前必须等待会话超时（最多 ~90 秒）。即使是仅包含 fastd 数据包类型标头的 1 字节 UDP 数据包也可触发更大的握手数据包（约 150 字节的 UDP 负载）。包括 IPv4 和 UDP 标头在内，生成的放大因子大约为 12-13。通过将带有伪造源地址的数据包发送到可在 Internet 上访问的 fastd 实例，这种 UDP 流量的放大可能会被用于发起分布式拒绝服务攻击。此漏洞在 v23 中已修复。 (CVE-2025-24356)

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

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

  - fastd は、IP パケットとイーサネットフレームを UDP 上でトンネリングする VPN デーモンです。IP アドレス/ポートの組み合わせが不明なデータパケットを受信すると、fastd は接続されたピアの 1 つが新しいアドレスに移動したと見なし、ハンドシェイクパケットを送信して再接続を開始します。この高速再接続により、新しい接続が確立されるまでセッションタイムアウト (最大 90 秒) を待つ必要がなくなります。fastd パケットタイプヘッダーを含むだけの 1 バイトの UDP パケットでさえ、はるかに大きなハンドシェイクパケット (~150 バイト UDP ペイロードまで) を発生させる可能性があります。IPv4 ヘッダーと UDP ヘッダーを含めると、増幅率は約 12 ～ 13 になります。偽装されたソースアドレスを含むデータパケットをインターネット上で到達可能な fastd インスタンスに送信することで、この UDP トラフィックの増幅が、分散型サービス拒否攻撃を助長するために利用される可能性があります。この脆弱性はv23で修正されています。 （CVE-2025-24356）

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

リモートの Fedora 41 ホストには、FEDORA-2025-b895b18cfe のアドバイザリに記載された脆弱性の影響を受けるパッケージがインストールされています。


    このリリースには、重要度低の脆弱性「CVE-2025-24356」の緩和策を含む、多数のマイナーな改善とバグ修正が含まれています。

    ## バグ修正

    - 高速再接続アンプ攻撃に対する緩和策を追加します

        未知の IP アドレス/ポートの組み合わせからデータパケットを受信する場合、fastd は、接続されているピアの 1 つが新しいアドレスに移動したと想定し (たとえば、動的 IP を持つインターネット回線、または WWAN とローカルインターネット接続の間のローミングなど)、ハンドシェイクパケットを送信して再接続を開始します。この高速再接続により、新しい接続が確立されるまでセッションタイムアウト (最大 90 秒) を待つ必要がなくなります。

        fastd パケットタイプヘッダーを含むだけの 1 バイトの UDP パケットでさえ、はるかに大きなハンドシェイクパケット (~150 バイト UDP ペイロードまで) を発生させる可能性があります。fastd v22 では、2 つのハンドシェイクが送信されるため (v22 より前と互換性のある形式で 1 つ、新しい L2TP 形式で 1 つ)、この数は 2 倍になります。IPv4 ヘッダーと UDP ヘッダーを含めると、増幅率は約 12 ～ 13 になります。

        偽装されたソースアドレスを含むデータパケットをインターネット上で到達可能な fastd インスタンスに送信することで、この UDP トラフィックの増幅が、分散型サービス拒否攻撃を助長するために利用される可能性があります。

        fastd は、この種の攻撃を回避するために、未知の IP アドレスとポートへのハンドシェイクのレート制限を常に 15 秒ごとに 1 回のハンドシェイクに実装しています。ただし、このレートはアドレスごとではなくポートごとに制限されているため、ハンドシェイクが同じ IP アドレスの 65535 個の UDP ポートすべてに無制限に送信される可能性があります。

        この問題は、多くの変更により fastd v23 で緩和されました:

        - レート制限が変更され、ポートごとではなくアドレスごとに適用されるようになりました

        - 高速再接続のために、2 回のハンドシェイクではなく 1 回のハンドシェイクのみが送信されます (データパケットの形式から、v22 より前のハンドシェイクを使用するか、L2TP スタイルのハンドシェイクを使用するかを決定します)

        - データパケットが有効であると見なされるためには、単一バイトではなく、少なくとも完全なメソッドヘッダーが必要です。これは、「null」メソッドを有効にするインスタンスには影響しません (「null」が実際に使用されているかどうかにかかわらず)。シングルバイト UDP パケットは有効な「null」キープアライブであるためですが、他のすべてのメソッドでは増幅係数が若干軽減されます。


        任意の IP アドレスからの接続を許可する fastd インスタンスのみが脆弱です。「remote」構成オプション ([Gluon](https://github.com/freifunk-gluon/gluon) ワイヤレスメッシュファームウェアの一部としての共通デプロイメントを含む) を使用してピアを構成するクライアントロールのインスタンスは、予期しないデータパケットにハンドシェイクで応答しないため、影響を受けません。

        「CVE-2025-24356」がこの問題に割り当てられました。この脆弱性の深刻度は「低」と見なされます。

        GitHub セキュリティアドバイザリは、[GHSA-pggg-vpfv-4rcv](https://github.com/neocturne/fastd/security/advisories/GHSA-pggg-vpfv-4rcv) で確認できます。

    - L2TP オフロードが fastd ビルドまたはカーネルによってサポートされていない場合に、「offload l2tp no;」で失敗する構成のロードを修正します

    - アセンブリ Salsa20(/12) の実装が、Linux 以外のシステムで Linux 固有の「.note.GNU-stack」ELF セクションを誤って生成する問題を修正します

        他のシステムは未知のセクションを無視するだけであるため、これが問題を引き起こす可能性は低いです。

    - ステータスソケット: - L2TP オフロードのインターフェース名情報を修正 - ピアごとの MTU 情報を追加

    - ドキュメント: - 不適切な永続インターフェースの例を修正します - 「float」オプションの説明を改善します

    - ビルド: - macOS のビルドを修正します (再度) - Meson 0.49 でビルドを修正します (fastd によってサポートされているとマークされた最小バージョン)


    ## その他の変更

    - x86 で間接ブランチトラッキングとシャドウスタックのサポートを追加します

        アセンブリ Salsa20(/12) の実装は、Intel CET (コントロールフロー強制テクノロジー) の一部である IBT および SHSTK と互換性があるとマークされており、「-fcf-protection」GCC オプションを使用して有効にできます。

    - ファイル「COPYRIGHT」は、名前が「LICENSE」に変更されました

    - 「libmnl_builtin=true」で使用される libmnl のベンダー化バージョンは、1.0.5 に更新されました



Tenable は、前述の記述ブロックを Fedora セキュリティアドバイザリから直接抽出しています。

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

リモートの Fedora 40 ホストには、FEDORA-2025-29fc4fefd5 のアドバイザリに記載された脆弱性の影響を受けるパッケージがインストールされています。


    このリリースには、重要度低の脆弱性「CVE-2025-24356」の緩和策を含む、多数のマイナーな改善とバグ修正が含まれています。

    ## バグ修正

    - 高速再接続アンプ攻撃に対する緩和策を追加します

        未知の IP アドレス/ポートの組み合わせからデータパケットを受信する場合、fastd は、接続されているピアの 1 つが新しいアドレスに移動したと想定し (たとえば、動的 IP を持つインターネット回線、または WWAN とローカルインターネット接続の間のローミングなど)、ハンドシェイクパケットを送信して再接続を開始します。この高速再接続により、新しい接続が確立されるまでセッションタイムアウト (最大 90 秒) を待つ必要がなくなります。

        fastd パケットタイプヘッダーを含むだけの 1 バイトの UDP パケットでさえ、はるかに大きなハンドシェイクパケット (~150 バイト UDP ペイロードまで) を発生させる可能性があります。fastd v22 では、2 つのハンドシェイクが送信されるため (v22 より前と互換性のある形式で 1 つ、新しい L2TP 形式で 1 つ)、この数は 2 倍になります。IPv4 ヘッダーと UDP ヘッダーを含めると、増幅率は約 12 ～ 13 になります。

        偽装されたソースアドレスを含むデータパケットをインターネット上で到達可能な fastd インスタンスに送信することで、この UDP トラフィックの増幅が、分散型サービス拒否攻撃を助長するために利用される可能性があります。

        fastd は、この種の攻撃を回避するために、未知の IP アドレスとポートへのハンドシェイクのレート制限を常に 15 秒ごとに 1 回のハンドシェイクに実装しています。ただし、このレートはアドレスごとではなくポートごとに制限されているため、ハンドシェイクが同じ IP アドレスの 65535 個の UDP ポートすべてに無制限に送信される可能性があります。

        この問題は、多くの変更により fastd v23 で緩和されました:

        - レート制限が変更され、ポートごとではなくアドレスごとに適用されるようになりました

        - 高速再接続のために、2 回のハンドシェイクではなく 1 回のハンドシェイクのみが送信されます (データパケットの形式から、v22 より前のハンドシェイクを使用するか、L2TP スタイルのハンドシェイクを使用するかを決定します)

        - データパケットが有効であると見なされるためには、単一バイトではなく、少なくとも完全なメソッドヘッダーが必要です。これは、「null」メソッドを有効にするインスタンスには影響しません (「null」が実際に使用されているかどうかにかかわらず)。シングルバイト UDP パケットは有効な「null」キープアライブであるためですが、他のすべてのメソッドでは増幅係数が若干軽減されます。


        任意の IP アドレスからの接続を許可する fastd インスタンスのみが脆弱です。「remote」構成オプション ([Gluon](https://github.com/freifunk-gluon/gluon) ワイヤレスメッシュファームウェアの一部としての共通デプロイメントを含む) を使用してピアを構成するクライアントロールのインスタンスは、予期しないデータパケットにハンドシェイクで応答しないため、影響を受けません。

        「CVE-2025-24356」がこの問題に割り当てられました。この脆弱性の深刻度は「低」と見なされます。

        GitHub セキュリティアドバイザリは、[GHSA-pggg-vpfv-4rcv](https://github.com/neocturne/fastd/security/advisories/GHSA-pggg-vpfv-4rcv) で確認できます。

    - L2TP オフロードが fastd ビルドまたはカーネルによってサポートされていない場合に、「offload l2tp no;」で失敗する構成のロードを修正します

    - アセンブリ Salsa20(/12) の実装が、Linux 以外のシステムで Linux 固有の「.note.GNU-stack」ELF セクションを誤って生成する問題を修正します

        他のシステムは未知のセクションを無視するだけであるため、これが問題を引き起こす可能性は低いです。

    - ステータスソケット: - L2TP オフロードのインターフェース名情報を修正 - ピアごとの MTU 情報を追加

    - ドキュメント: - 不適切な永続インターフェースの例を修正します - 「float」オプションの説明を改善します

    - ビルド: - macOS のビルドを修正します (再度) - Meson 0.49 でビルドを修正します (fastd によってサポートされているとマークされた最小バージョン)


    ## その他の変更

    - x86 で間接ブランチトラッキングとシャドウスタックのサポートを追加します

        アセンブリ Salsa20(/12) の実装は、Intel CET (コントロールフロー強制テクノロジー) の一部である IBT および SHSTK と互換性があるとマークされており、「-fcf-protection」GCC オプションを使用して有効にできます。

    - ファイル「COPYRIGHT」は、名前が「LICENSE」に変更されました

    - 「libmnl_builtin=true」で使用される libmnl のベンダー化バージョンは、1.0.5 に更新されました



Tenable は、前述の記述ブロックを Fedora セキュリティアドバイザリから直接抽出しています。

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

ID	名稱	產品	系列	已發布	已更新	嚴重性
231784	Linux Distros 未修補弱點：CVE-2025-24356	Nessus	Misc.	2025/3/6	2025/9/3	medium
214935	Fedora 41 : fastd (2025-b895b18cfe)	Nessus	Fedora Local Security Checks	2025/2/4	2025/8/27	medium
214990	Fedora 40 : fastd (2025-29fc4fefd5)	Nessus	Fedora Local Security Checks	2025/2/5	2025/8/27	medium
231784	Linux Distros Unpatched Vulnerability : CVE-2025-24356	Nessus	Misc.	2025/3/6	2025/9/3	medium
231784	Linux Distros 未修补的漏洞: CVE-2025-24356	Nessus	Misc.	2025/3/6	2025/9/3	medium
231784	Linux Distros のパッチ未適用の脆弱性: CVE-2025-24356	Nessus	Misc.	2025/3/6	2025/9/3	medium
214935	Fedora 41fastd2025-b895b18cfe	Nessus	Fedora Local Security Checks	2025/2/4	2025/8/27	medium
214990	Fedora 40 : fastd (2025-29fc4fefd5)	Nessus	Fedora Local Security Checks	2025/2/5	2025/8/27	medium

偵測

搜尋 Plugin

medium

medium

medium

medium

medium

medium

medium

medium