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

  - net： stmmac：當 RX 記憶體耗盡時，防止 NULL 解除參照 CPU 透過傳統 DMA 從 MAC 接收幀：CPU 為 MAC 分配緩衝區，然後 MAC 填充它們並將所有權歸還給 CPU。針對每個硬體 RX 佇列，CPU 和 MAC 會透過 DMA 描述元的共用環形陣列進行協調：每個 DMA 緩衝區一個描述元。每個描述元都包含緩衝區的實體位址和狀態旗標 （OWN），指示哪一方擁有緩衝區：CPU 的 OWN=0，MAC 的 OWN=1。CPU 只允許設定旗標，MAC 只允許清除旗標，兩者都必須依序穿過環：因此環用於提交和完成。在 stmmac 驅動程式中，stmmac_rx（） 會使用「cur_rx」索引為其在環中的位置加上書籤。該函式中的主接收迴圈會檢查 rx_descs[cur_rx].own=0，將對應的緩衝區提供給網路堆疊 （將指標設為 NULL），並以 'cur_rx' 為模環大小遞增。迴圈退出後，stmmac_rx_refill（） 會用「dirty_rx」為其位置加上書籤，配置新的緩衝區並重新武裝描述元（設定 OWN=1）。如果任何配置失敗，它只會提前停止（留下 OWN=0），並在下次呼叫時從中斷的地方重試。這意味著描述符具有三個階段的生命週期（我自己的術語）： - 'empty' （OWN=1，緩衝區有效） - 'full' （OWN=0，緩衝區有效且已填充） - 'dirty' （OWN=0，緩衝區 NULL） 但由於 stmmac_rx（） 只檢查 OWN，所以它混淆了 'full'/'dirty'。過去 （請參閱「修正：」），有一個錯誤，即迴圈可能會循環 'cur_rx' 一直回到它弄髒的第一個描述元，導致在被誤認為「full」時出現 NULL 解除參照。上述提交透過將迴圈的迭代限制為「dma_rx_size - 1」來解決該*特定*失敗，但這只是部分修復：如果先前的 stmmac_rx_refill（） 未完成，則迴圈可能會遇到剩餘的「髒」描述符，而無需完全循環。因此，當 stmmac_rx_refill（） 記憶體不足足夠長以使 'cur_rx' 趕上 'dirty_rx' 時，當前代碼會發生錯誤 （參見 'Closes：'）。透過在前進「cur_rx」之前明確檢查下一個項目是否為髒項目來修正此問題;如果是，請結束迴圈。這可以防止在 stmmac_rx_refill（） 成功之前處理最終使用的描述項，但完全防止了先前錯誤修正所期望的「cur_rx == dirty_rx」歧義：因此也移除了夾具。由於 stmmac_rx_zc（） 是 stmmac_rx（） 的複製貼上和調整，並且程式碼結構相同，因此對 stmmac_rx（） 的任何修復也需要對 stmmac_rx_zc（） 進行相應的修復。因此，請在那裡套用相同的檢查。
    在 stmmac_rx（） （不是 stmmac_rx_zc（）） 中，仍然存在一個相關的錯誤：在 MAC 在最終描述項上設定 OWN=0 之後，它將無法傳送任何進一步的 DMA 完成 IRQ，直到給出更多「空」描述項。目前，驅動程式只是「希望」下一個 stmmac_rx_refill（） 成功，否則可能會面臨接收進程無限期停止的風險。但這不是回歸，因此可以在未來的變更中解決。（CVE-2026-46110）

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

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

  - net：stmmac：RX 内存耗尽时防止空取消引用 CPU 通过常规 DMA 从 MAC 接收帧：CPU 为 MAC 分配缓冲区，然后 MAC 填充缓冲区并将所有权返回给 CPU。对于每个硬件 RX 队列，CPU 和 MAC 通过 DMA 描述符的共享环形数组进行协调：每个 DMA 缓冲区一个描述符。每个描述符都包括缓冲区的物理地址和指示哪一端拥有缓冲区的状态标志 （OWN）：CPU 表示 OWN=0，MAC 表示 OWN=1。CPU 只允许设置标志，MAC 只允许清除标志，两者都必须按顺序通过环：因此环用于提交和完成。在 stmmac 驱动程序中，stmmac_rx（） 会使用“cur_rx”索引为自己在环中的位置添加书签。该函数中的主要接收循环会检查 rx_descs[cur_rx].own=0，将相应的缓冲区提供给网络堆栈（指针为空），并以环大小为模数递增 'cur_rx'。循环退出后，stmmac_rx_refill（） 会将其位置添加为书签，并以“dirty_rx”添加书签，分配新的缓冲区并重新设置描述符（设置 OWN=1）。如果它失败了任何分配，它只是提前停止（保留 OWN=0），并在下次调用时从中断的地方重试。这意味着描述符有三个阶段的生命周期（我自己的术语）：- 'empty' （OWN=1， buffer valid） - 'full' （OWN=0， buffer valid and populated） - 'dirty' （OWN=0， buffer NULL） 但因为 stmmac_rx（） 只检查 OWN，所以混淆了 'full'/'dirty'。过去（请参见“补丁：”），存在一个缺陷，循环可一直循环“cur_rx”，回到它脏化的第一个描述符，导致被误认为“full”时出现空取消引用。上述提交通过将循环的迭代限制上限设为“dma_rx_size - 1”解决了该 *特定* 失败，但这只是部分补丁：如果之前的 stmmac_rx_refill（） 未完成，则循环可能需要完全循环的情况下可能会遇到残留的“脏”描述符。因此，当 stmmac_rx_refill（） 的内存匮乏时间足够长以至于“cur_rx”赶上“dirty_rx”时，当前代码会发生错误（请参阅“Closes：”）。通过在前进“cur_rx”之前显式检查下一个条目是否为脏来修复此问题;如果是，则退出循环。这将阻止处理最终的、使用的描述符，直到 stmmac_rx_refill（） 成功，但完全阻止了上一个缺陷补丁预期的“cur_rx == dirty_rx”歧义：因此也删除该钳子。由于 stmmac_rx_zc（） 是 stmmac_rx（） 的复制粘贴和调整方式，且代码结构相同，因此任何针对 stmmac_rx（） 的补丁也都需要针对 stmmac_rx_zc（） 的相应补丁。因此，请在此处应用相同的检查。
    在 stmmac_rx（）（而非 stmmac_rx_zc（））中仍然存在一个相关缺陷：MAC 在最终描述符上设置 OWN=0 之后，在给予更多“空”描述符之前，它将无法再发送任何 DMA 完成的 IRQ。目前，驱动程序只是*希望*下一个 stmmac_rx_refill（） 成功，否则有接收进程无限期停止的风险。但这不是回归，因此可在未来的更改中解决。（CVE-2026-46110）

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

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

  - net:stmmac:RX メモリ消耗時の NULL デリファレンスを防ぎます。CPU は、従来の DMA を通じて MAC からフレームを受信します:CPU がバッファを MAC に割り当て、MAC がバッファを満たし、所有権を CPU に戻します。各ハードウェア RX キューでは、CPU と MAC が、DMA 記述子(DMA バッファごとに 1 つの記述子)の共有リング配列を通じて調整します。各記述子には、バッファの物理アドレスと、バッファを所有する側を示すステータスフラグ(OWN)が含まれます。CPU の場合は OWN=0、MAC の場合は OWN=1。CPU はフラグを設定することだけが許可され、MAC はフラグをクリアすることしか許可されず、両方が順番にリングを通過する必要があります。したがって、リングは提出と完了の両方に使用されます。stmmac ドライバーで、stmmac_rx() は「cur_rx」インデックスでリング内の位置をブックマークします。関数が rx_descs[cur_rx].own=0 をチェックし、ネットワークスタックに対応するバッファを提供し(ポインターを NULL に)、リングサイズを「cur_rx」モジュロにインクリメントするメイン受信ループ。ループが終了した後、stmmac_rx_refill() は、その位置を「dirty_rx」でブックマークし、新しいバッファを割り当て、記述子を再起動します(OWN=1 を設定)。割り当てに失敗した場合は、単に早期に停止し(OWN=0 のまま)、次に呼び出されたときに中断したところから再試行します。これは、記述子には3段階のライフサイクルがあることを意味します(私自身の用語):- 'empty' (OWN=1、バッファ有効) - 'full' (OWN=0、バッファ有効で配置済み) - 'dirty' (OWN=0、バッファNULL)しかし、stmmac_rx()はOWNのみをチェックするため、「full」/「dirty」を混同します。過去には(「修正」を参照)、ループが「cur_rx」を循環して、汚した最初の記述子まで戻って、「full」と間違えられると NULL デリファレンスを引き起こすバグがありました。前述のコミットでは、ループの反復制限を「dma_rx_size - 1」に制限することで、この*特定の*失敗を解決しましたが、これは部分的な修正にすぎません。以前の stmmac_rx_refill() が完了しなかった場合、ループが、完全に循環する必要なしに遭遇する可能性のある「ダーティ」な記述子が残ります。したがって、現在のコードは、「cur_rx dirty_rx」が「」に追いつくのに十分な時間、stmmac_rx_refill() がメモリ枯渇状態になると、パニック(「Closes:」を参照)が発生します。「cur_rx」に進む前に、次のエントリがダーティであるかどうかを明示的にチェックすることで、これを修正します。ループが存在する場合はループを終了します。これにより、stmmac_rx_refill() が成功するまで、最終の使用された記述子の処理が妨げられますが、以前のバグ修正が意図したように「cur_rx == dirty_rx」の不明瞭さを完全に防止します。このため、クランプも削除します。stmmac_rx_zc() は stmmac_rx() のコピーして調整できるもので、コード構造は同一であるため、stmmac_rx() の修正には stmmac_rx_zc() に対応する修正も必要です。したがって、ここで同じチェックを適用します。
    stmmac_rx()(stmmac_rx_zc() ではなく)に、関連するバグが残っています。MAC が最後の記述子に OWN=0 を設定した後、より多くの「空の」記述子が与えられるまで、それ以上 DMA-complete IRQ を送信することができません。現在、ドライバーは、次の stmmac_rx_refill() が成功することを単に「期待」しており、成功しない場合は、受信プロセスが無期限にストールするリスクがあります。ただし、これは回帰ではないため、今後の変更で対処できます。(CVE-2026-46110)

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

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

  - net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through     conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to     the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA     descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a     status flag (OWN) indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only     allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in     sequence: thus the ring is used for both submissions and completions. In the stmmac driver,     stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that     function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing     the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(),     which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting     OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off     when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1,     buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because     stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where     the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL     dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by     capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous     stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might     encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when     stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by     explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This     prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents     the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since     stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to     stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there.
    In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final     descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty`     descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an     indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a     future change. (CVE-2026-46110)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
317581	Linux Distros 未修補的弱點：CVE-2026-46110	Nessus	Misc.	2026/5/29	2026/6/1	high
317581	Linux Distros 未修补的漏洞：CVE-2026-46110	Nessus	Misc.	2026/5/29	2026/6/1	high
317581	Linux Distros のパッチ未適用の脆弱性: CVE-2026-46110	Nessus	Misc.	2026/5/29	2026/6/1	high
317581	Linux Distros Unpatched Vulnerability : CVE-2026-46110	Nessus	Misc.	2026/5/29	2026/6/1	high

检测

插件搜索

high

high

high

high