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

  - ring-buffer：使用強制 8 位元組對齊來固定事件長度 當 RB_FORCE_8BYTE_ALIGNMENT 為 true 時，rb_calculate_event_length（） 會保留 event->array[0] 的空間來放置資料長度，而 rb_update_event（） 會相應地將資料長度儲存在 event->array[0] 中。因此，整個事件長度將無條件地為 sizeof（event.array[0]） 增加額外的 4 個位元組。但 ring_buffer_event_length（） 只會針對大於 RB_MAX_SMALL_DATA + sizeof（event->array[0]） 的事件減去 sizeof（event->array[0]）。因此，具有 RB_FORCE_8BYTE_ALIGNMENT=true 的架構上的小型事件會報告比預期大 4 個位元組的資料長度。若要修正此問題，請將RB_FORCE_8BYTE_ALIGNMENT新增為條件，以在 RB_FORCE_8BYTE_ALIGNMENT 為 true 時減去該長度欄位的大小。在 CONFIG_HAVE_64BIT_ALIGNED_ACCESS 設定為 y 的 riscv64 核心中觀察到此問題，當我們執行 ftrace selftest trace_marker_raw.tc 時，我們得到一個奇怪的日誌：對於 id 為 1..100 的情況，資料欄位的數量為 8*N，但一旦 id 超過 100，資料欄位的數量就會變成 8*N+4： # 1 buf： 58 00 00 00 80 5e d1 63 （資料欄位數為 8*1） ... # a buf： 58 ...（資料欄位數為 8*2） ... # 64 buf： 58 ...
    （資料欄位數為 8*13） # 65 buf： 58 ...（資料欄位數為8*13+4）套用此變更後，資料欄位數會持續維持為 8*N+4。（CVE-2026-80876）

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

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

  - ring-buffer：通过强制 8 字节对齐修复事件长度 RB_FORCE_8BYTE_ALIGNMENT为 true 时，rb_calculate_event_length（） 将 event->array[0] 的空间预留用于放置数据长度，而 rb_update_event（） 相应地将数据长度存储在 event->array[0] 中。因此，整个事件长度将无条件地为 sizeof（event.array[0]） 额外增加 4 个字节。但是 ring_buffer_event_length（） 仅减去大于 RB_MAX_SMALL_DATA + sizeof（event->array[0]） 的事件的 sizeof（event->array[0]）。因此，RB_FORCE_8BYTE_ALIGNMENT=true 架构上的小型事件会报告比预期大 4 个字节的数据长度。要修复此问题，请添加该RB_FORCE_8BYTE_ALIGNMENT作为条件，以便在 RB_FORCE_8BYTE_ALIGNMENT 为 true 时减去该长度字段的大小。在 CONFIG_HAVE_64BIT_ALIGNED_ACCESS 设置为 y 的 riscv64 内核中运行 ftrace selftest trace_marker_raw.tc 时发现此问题，得到奇怪的日志：对于 id 为 1..100 的情况，数据字段数为 8*N，但一旦 id 超过 100，数据字段数变为 8*N+4： # 1 buf：58 00 00 00 80 5e d1 63（数据字段数为 8*1）... # a buf：58 ...（数据字段的数量为 8*2） ... # 64 缓冲器：58 ...
    （数据字段数为 8*13） # 65 缓冲器：58 ...（数据字段数为8*13+4）应用该更改后，数据字段的数量始终保持为 8*N+4。（CVE-2026-80876）

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

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

  - ring-buffer:強制された 8 バイトアライメントでイベント長を修正します RB_FORCE_8BYTE_ALIGNMENT が true の場合、rb_calculate_event_length() はデータ長を配置するために event->array[0] のスペースを確保し、それに応じて rb_update_event() はデータ長を event->array[0] に保存します。その結果、イベントの長さ全体が sizeof(event.array[0]) に対して無条件で 4 バイト余分に追加されます。ただし、ring_buffer_event_length()は、RB_MAX_SMALL_DATA + sizeof(event->array[0])よりも大きいイベントのsizeof(event->array[0])を減算するだけです。その結果、RB_FORCE_8BYTE_ALIGNMENT=trueのアーキテクチャの小さなイベントにより、予想よりも4バイト長いデータ長が報告されます。これを修正するには、RB_FORCE_8BYTE_ALIGNMENTが真の場合は常にその長さフィールドのサイズを減算する条件としてRB_FORCE_8BYTE_ALIGNMENTを追加します。この問題は、CONFIG_HAVE_64BIT_ALIGNED_ACCESS が y に設定された riscv64 カーネルで見られます。ftrace セルフテスト trace_marker_raw.tc を実行すると、奇妙なログが取得されます。id が 1..100 の場合、データフィールドの数は 8*N ですが、id が 100 を超えるとデータフィールドの数は 8*N+4 になります。 # 1 buf: 58 00 00 00 80 5e d1 63 (データフィールドの数は 8*1) ... # A buf: 58 ...(データフィールド数は8*2)... #64 buf:58 ...
    (データフィールド数は8*13)#65 buf:58 ...(データフィールド数は8*13+4)この変更の適用後、データフィールドの数は一貫して 8*N+4 のままになります。(CVE-2026-80876)

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

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

  - ring-buffer: Fix event length with forced 8-byte alignment When RB_FORCE_8BYTE_ALIGNMENT is true,     rb_calculate_event_length() reserves the space of event->array[0] for placing the data length and     rb_update_event() stores the data length in event->array[0] accordingly. As a result the whole event     length will add extra 4 bytes for sizeof(event.array[0]) unconditionally. But ring_buffer_event_length()     only subtracts the sizeof(event->array[0]) for events larger than RB_MAX_SMALL_DATA +     sizeof(event->array[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALIGNMENT=true     report a data length that is 4 bytes larger than expected. To fix it, add the RB_FORCE_8BYTE_ALIGNMENT as     a condition to subtract the size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is true. This     issue is observed in a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace     selftest trace_marker_raw.tc, we get the weird log: for cases where the id is 1..100, the number of data     field is 8*N, but once id exceeds 100, the number of data field becomes 8*N+4: # 1 buf: 58 00 00 00 80 5e     d1 63 (number of data field is 8*1) ... # a buf: 58 ... (number of data field is 8*2) ... # 64 buf: 58 ...
    (number of data field is 8*13) # 65 buf: 58 ... (number of data field is 8*13+4) After applying this     change, the number of data field keeps being 8*N+4 consistently. (CVE-2026-80876)

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

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

检测

插件搜索

medium

medium

medium

medium