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

  - netfs修正中間有 EOF 的頁面提前讀取解除鎖定。在某些情況下緩衝讀取的讀取結果收集似乎會在子要求完成之前執行如下列記錄程式碼所示9p_client_res用戶端 18446612686390831168 回應 P9_TREAD 標籤0 錯誤 0 ...
    netfs_sreqR=00001b55[1] 關閉期限 f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004讀取完成 netfs_folio i=157f3 ix=00004-00004 讀取解鎖 netfs_collect_folioR=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio
    i=157f3 ix=00005-00005 讀取完成 netfs_folio i=157f3 ix=00005-00005 讀取解鎖 ... netfs_collect_stream
    R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln= 6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4es=0 e=0 netfs_sreq: R=00001b55[2] ZERO SUBMT f=102 s=5fb2 4e/ 4e s=5 e=0「cto=5fb2」表示到目前為止我們已收集結果的檔案 pos - 但還有 0x4e 位元組要執行 - 因此我們不應收集 folio ix=00005 。會清除結尾的「ZERO」subreq 會在我們解除鎖定作品集之後發生進而允許應用程式透過 mmap 查看未清除的結尾。問題在於 netfs_read_unlock_folios() 會解除鎖定作品集其中收集的讀取結果數量達到 EOF 位置但 ZERO subreq 超出此範圍因此會發生在之後。透過將結尾檢查變更為一律是作品集的結尾而不是檔案的結尾來修正此問題。未來我應該在這裡考慮清除到作品集的結尾而不是新增 ZERO subreq 來執行此操作。另一方面ZERO subreq 可與 async READ subreq 平行執行。此外可能仍需要 ZERO subreq (例如處理 ceph 檔案中沒有任何備份儲存區因此隱含全為零的範圍)。若要重現此問題可以建立檔案使其大小未與頁面邊界對齊 (例如 24998 (0x5fb2) 位元組)然後執行類似 xfs_io -c mmap -r 0 0x6000 -c madvise -d 0 0x6000 \ -c mread -v 0 0x6000 /xfstest.test/x 最後 0x4e 位元組應全部為 00但如果尚未清除結尾可能會在這裡看到無用內容。透過將核心修改為停用 netfs_read_subreq_progress() 呼叫並阻止 afs_issue_read() 執行 NETFS_READAHEAD 的 async 呼叫的 kafs 可使用 kafs 重現此問題。針對 ZERO-subreq 情況在 netfs_issue_read() 中插入 mdelay(100)可簡化複製作業。AFS 與 CIFS 通常不太可能顯示此問題因為它們會非同步分派 READ ops進而允許 ZERO-subreq 先完成。 9P 的 READ op 是完全同步的因此 ZERO-subreq 將一律在其後發生。不過也不一定會隨時出現因為收集可能是在背景工作執行緒中完成。 (CVE-2025-71201)

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

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

  - netfs修复 EOF 在中间的页面的提前读取解锁 在某些情况下缓冲读取的读取结果集合似乎在子请求完成之前完成运行这一点可以在以下日志片段中看到9p_client_res客户端 18446612686390831168 响应 P9_TREAD 标签0 err 0 ...
    netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio i=157f3 ix=00004-00004 read-unlock netfs_collect_folioR=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio
    i=157f3 ix=00005-00005 read-done netfs_folio i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream
    R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln= 6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/ 4e s=5 e=0 “cto=5fb2”表示我们已将结果收集到 pos 的已收集文件 - 但仍有 0x4e 个字节需要处理 - 因此我们尚未应收集 folio ix=00005 。我们解锁 folio 之后会发生可清除尾部的“ZERO”子req从而允许应用程序通过 mmap 查看未清除的尾部。问题在于 netfs_read_unlock_folios() 将解锁一个作品集，其中收集的读取结果数量达到 EOF 位置 - 但 ZERO subreq 在此范围之外发生因此之后会发生。通过将结束检查更改为始终作为作品集的结尾而非文件的结尾来修复此问题。以后我应该考虑清除到此处作品集的末尾而不是添加 ZERO subreq 来实现此目的。另一方面ZERO subreq 可与 async READ subreq 并行运行。此外可能仍然需要 ZERO subreq例如处理 ceph 文件中没有任何后备存储因此隐式全零的盘区。通过创建大小与页面边界未对齐如 24998 (0x5fb2) 字节的文件可重现此问题然后执行类似以下的操作 xfs_io -c mmap -r 0 0x6000 -c madvise -d 0 0x6000 \ -c mread -v 0 0x6000 /xfstest.test/x 最后 0x4e 字节应全部为 00但如果尚未清除尾部则可能会在该处看到垃圾。通过修改内核以禁用对 netfs_read_subreq_progress() 的调用并停止 afs_issue_read()执行 NETFS_READAHEAD 的异步调用可以使用 kafs 重现此问题。对于 ZERO-subreq 的情况在 netfs_issue_read() 中插入 mdelay(100)可让重现变得更容易。AFS 和 CIFS 通常不太可能显示此问题，因为它们以异步方式调度 READ ops，这允许 ZERO-subreq 首先完成。 9P 的 READ 操作是完全同步的因此 ZERO-subreq 之后将始终发生。但该图标并非始终可见，因为可能会在工作线程中完成收集。 (CVE-2025-71201)

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

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

  - netfs中間の EOF のあるページの早期読み取りのロック解除を修正します。次のログスニペットで見られるように、バッファされた読み取りの読み取り結果コレクションは、状況によってはサブリクエストの完了に先がけて実行されるようです 9p_client_resクライアント 18446612686390831168 応答 P9_TREAD タグ0 err 0 ...
    netfs_sreqR=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folioR=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio i=157f3 ix=00004-00004 read-done netfs_folio i=157f3 ix=00004-00004 read-unlock netfs_collect_folioR=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio
    i=157f3 ix=00005-00005 read-done netfs_folio i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream
    R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln= 6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/ 4e s=5 e=0 「cto=5fb2」は、これまで結果を収集していた収集ファイル pos を示します - しかし、まだ 0x4e のバイト数があり、folio はまだ収集されていないはずです ix=00005 。テールをクリアする「ZERO」subreq は、folio をロック解除した後に発生します。これにより、アプリケーションは mmap を通じて不明確なテールを確認できます。問題は、netfs_read_unlock_folios() が folio のロックを解除するときに、収集された読み取り結果の量が EOF 位置にヒットするが、ZERO subreq はその範囲を超えるため、その後に発生するということです。ファイルの終端ではなく常に folio の終端であるように、エンドチェックを変更することでこれを修正します。将来的には、これを行うために ZERO subreq を追加するのではなく、ここで folio の終わりまでクリアすることを検討する必要があります。それに対して、ZERO subreq は async READ subreq と並列に実行される可能性があります。さらに、たとえば、バッキングストアがなく、暗黙的にすべてゼロである ceph ファイルのエクステントを処理するには、ZERO subreq が依然として必要である可能性があります。これは、24998 (0x5fb2) バイトなどのページ境界に整列しないファイルを作成してから、次のように実行することで発生する可能性がありますxfs_io -c mmap -r 0x6000 -c madvise -d 0 0x6000 \ -c mread -v 0 0x6000 /xfstest.test/x 最後の 0x4e バイトはすべて 00 になるはずですが、テールがまだクリアされていない場合、そこに rubbish が表示されることがあります。これは、カーネルを変更して netfs_read_subreq_progress() への呼び出しを無効にし、afs_issue_read() が NETFS_READAHEAD の async 呼び出しを停止するように停止することで、kafs で発生します。ZERO-subreq の場合、netfs_issue_read() に mdelay(100) を挿入することで、再生成をより簡単にできます。AFS と CIFS は READ ops を非同期的にディスパッチするため、通常これを示しません。これにより、ZERO-subreq が最初に完了します。 9P の READ op は完全に同期するため、ZERO-subreq は常にその後に発生します。ただし、収集はワーカースレッドで行われる場合があるため、常に確認されるわけではありません。CVE-2025-71201

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

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

  - netfs: Fix early read unlock of page with EOF in middle The read result collection for buffered reads     seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the     following log snippet: 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0 ...
    netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55     ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3     ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio:
    i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream:
    R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c     netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2     cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2]     ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0 The 'cto=5fb2' indicates the collected file pos we've collected     results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio     ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the     application to see the uncleared tail through mmap. The problem is that netfs_read_unlock_folios() will     unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies     beyond that and so happens after. Fix this by changing the end check to always be the end of the folio and     never the end of the file. In the future, I should look at clearing to the end of the folio here rather     than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async     READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that     don't have any backing store and are thus implicitly all zeros. This can be reproduced by creating a file,     the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something     like: xfs_io -c mmap -r 0 0x6000 -c madvise -d 0 0x6000 \ -c mread -v 0 0x6000 /xfstest.test/x The     last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This     can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress()     and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made     easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case. AFS and CIFS are     normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to     finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It     isn't seen all the time, though, because the collection may be done in a worker thread. (CVE-2025-71201)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
299223	Linux Distros 未修補的弱點：CVE-2025-71201	Nessus	Misc.	2026/2/16	2026/3/19	high
299223	Linux Distros 未修补的漏洞：CVE-2025-71201	Nessus	Misc.	2026/2/16	2026/3/19	high
299223	Linux Distros のパッチ未適用の脆弱性: CVE-2025-71201	Nessus	Misc.	2026/2/16	2026/3/19	high
299223	Linux Distros Unpatched Vulnerability : CVE-2025-71201	Nessus	Misc.	2026/2/16	2026/3/19	high

检测

插件搜索

high

high

high

high