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

  - bpf：修正因原子取指精確追蹤而產生的錯誤剪枝。當backtrack_insn遇到帶有 BPF_ATOMIC 和 BPF_FETCH 的 BPF_STX 指令時，src 暫存器（或 r0 表示 BPF_CMPXCHG）也作為目的地，從記憶體位置接收舊值。目前的回溯邏輯並未考慮到這點。它將原子擷取操作視為一般儲存，僅將 src 暫存器視為輸入。這會導致backtrack_insn無法將精確度傳遞到堆疊位置，導致堆疊位置無法被標記為精確！之後，驗證者的路徑剪枝可能會錯誤地將兩個狀態視為等價，當它們在堆疊狀態上不同時。也就是說，兩個分支可以被視為等價，因此在不該被視為這樣的情況下卻被修剪。修正方式如下：在 backtrack_insn 中擴展 BPF_LDX 處理，也透過 is_atomic_fetch_insn（） 輔助工具涵蓋原子擷取操作。當擷取 DST 暫存器被追蹤精度時，清除它，並將精度傳遞到堆疊插槽。對於非堆疊記憶體，精確步走在原子指令處停止，與一般BPF_LDX相同。
    這涵蓋了所有撿球變體。之前：0：（b7） r1 = 8;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3：（db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=fp0 5： （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= before 4： （bf） r3 = r10 mark_precise：
    Frame0： regs=r2 stack= 3之前： （dB） R2 = atomic64_fetch_add（（U64 *）（R10 -8）， R2） mark_precise： frame0：
    regs=r2 堆疊=在 2 之前：（b7） r2 = 0 6： R2=8 R3=fp8 6： （b7） r0 = 0;R0=0 7：（95） 結束 之後：0：（b7） r1 = 8 ;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3：（db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=fp0 5：
    （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= before 4： （bf） r3 = r10 mark_precise： frame0： regs=r2 stack= before 3： （db） r2 = atomic64_fetch_add（（u64 *）（r10 -8）， r2） mark_precise： frame0： regs= stack=-8 before 2： （b7） r² = 0 mark_precise： Frame0： regs= stack=-8 前 1： （7b） *（U64 *）（R10 -8） = R1 mark_precise： frame0： regs=r1 stack= before 0： （b7） r1 = 8 6： R2=8 R3=FP8 6： （B7） R0 = 0 ;R0=0 7： （95） 出口 （CVE-2026-43009）

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

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

  - bpf：修复因原子取指精确跟踪导致的错误剪枝。当backtrack_insn遇到BPF_ATOMIC和BPF_FETCH的BPF_STX指令时，src寄存器（或r0表示BPF_CMPXCHG）也作为目的地，从而从内存位置接收旧值。当前的回溯逻辑并未考虑到这一点。它将原子取指操作视为普通存储，src寄存器仅作为输入。这导致backtrack_insn无法将精度传递到栈位置，导致堆栈位置不被标记为精确！之后，验证者的路径修剪可能会错误地将两个状态视为等价，尽管它们在栈态上不同。也就是说，两个分支可以被视为等价的，因此在不该被视为这样的情况下被修剪。修复如下：在backtrack_insn中扩展BPF_LDX处理，也通过is_atomic_fetch_insn（）辅助工具覆盖原子取指操作。当取指DST寄存器被跟踪以保证精度时，清除它，并将精度传递到栈槽。对于非栈内存，精确游走在原子指令处停止，与普通 BPF_LDX 相同。
    这涵盖了所有取球变体。之前：0：（b7） r1 = 8;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3： （db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=FP0 5： （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= 在4之前： （bf） r3 = r10 mark_precise：
    帧0：regs=r2堆叠=在3之前：（dB） R2 = atomic64_fetch_add（（U64 *）（R10 -8）， R2） mark_precise： frame0：
    regs=r² 栈= 2之前： （b7） r² = 0 6： R²=8 R3=fp8 6： （b7） r₀ = 0;R0=0 7： （95） 退出 之后：0： （b7） r1 = 8;R1=8 1： （7b） *（u64 *）（r10 -8） = r1;R1=8 R10=fp0 fp-8=8 2： （b7） r² = 0;R2=0 3： （db） r² = atomic64_fetch_add（（u64 *）（r10 -8）， r²）;R2=8 R10=fp0 fp-8=mmmmmmmm 4： （bf） r3 = r10;R3=fp0 R10=fp0 5：
    （0f） r3 += r2 mark_precise： frame0： last_idx 5 first_idx 0 subseq_idx -1 mark_precise： frame0： regs=r2 stack= before 4： （bf） r3 = r10 mark_precise： frame0： regs=r2 stack= before 3： （db） r2 = atomic64_fetch_add（（U64 *）（R10 -8）， R2） mark_precise： frame0： regs= stack=-8 before 2： （b7） r2 = 0 mark_precise： 帧0：regs= stack=-8 之前 1： （7b） *（U64 *）（R10 -8） = R1 mark_precise： frame0： regs=r1 stack= before 0： （b7） r1 = 8 6： R2=8 R3=FP8 6： （B7） R0 = 0;R0=0 7： （95） exit （CVE-2026-43009）

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

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

  - bpf:原子的フェッチ精度トラッキングによる誤った剪定を修正backtrack_insn BPF_ATOMICとBPF_FETCHのBPF_STX命令に遭遇すると、srcレジスタ(またはBPF_CMPXCHGの場合はr0)が宛先としても機能し、メモリ位置から古い値を受信します。現在のバックトラッキングのロジックではこれを考慮していません。アトミックフェッチ操作は通常のストアと同様に扱い、srcレジスタは入力のみとなります。これにより、backtrack_insnが精度をスタックの位置に伝播できず、その位置が正確としてマークされなくなります! 後に、検証者のパスプルーニングはスタック状態が異なる場合、2つの状態を誤って同値とみなすことがあります。つまり、二つの枝が同等扱いされ、本来見るべきでないのに剪定される可能性があるということです。次のように修正します:backtrack_insnのBPF_LDX処理を拡張し、is_atomic_fetch_insn()ヘルパーを使ってアトミックフェッチ操作もカバーします。フェッチDSTレジスタが精度のために追跡される際は、それをクリアし、精度をスタックスロットに伝播させます。非スタックメモリの場合、精密歩行は通常のBPF_LDXと同様に原子命令で停止します。
    これはすべての取ってこいバリエーションをカバーしています。前:0:(b7) r1 = 8 ;R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ;R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ;R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ;R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ;R3=FP0 R10=FP0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= 4の前: (bf) r3 = r10 mark_precise:
    frame0: regs=r2 stack= 3 前: (dB) R2 = atomic64_fetch_add((U64 *)(R10 -8), R2) mark_precise: frame0:
    regs=r2 スタック= 2の前:(b7) r2 = 0 6: R2=8 R3=FP8 6: (b7) R0 = 0;R0=0 7: (95) 終了 後:0: (b7) r1 = 8 ;R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ;R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ;R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ;R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ;R3=fp0 R10=fp0 5:
    (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= 3より前: (db) r2 = atomic64_fetch_add((u64 *)(R10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= スタック=-8 1: (7b) *(U64 *)(R10 -8) = R1 mark_precise: frame0: regs=r1 スタック= Before 0: (B7) R1 = 8 6: R2=8 R3=FP8 6: (B7) R0 = 0;R0=0 7: (95) 出口(CVE-2026-43009)

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

An update of the linux package has been released.

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

  - bpf: Fix incorrect pruning due to atomic fetch precision tracking When backtrack_insn encounters a BPF_STX     instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a     destination, thus receiving the old value from the memory location. The current backtracking logic does     not account for this. It treats atomic fetch operations the same as regular stores where the src register     is only an input. This leads the backtrack_insn to fail to propagate precision to the stack location,     which is then not marked as precise! Later, the verifier's path pruning can incorrectly consider two     states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as     equivalent and thus get pruned when they should not be seen as such. Fix it as follows: Extend the BPF_LDX     handling in backtrack_insn to also cover atomic fetch operations via is_atomic_fetch_insn() helper. When     the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack     slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPF_LDX.
    This covers all fetch variants. Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0     fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0     fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5     first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise:
    frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0:
    regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit After: 0: (b7) r1 =     8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 =     atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5:
    (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2     stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 =     atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0     mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1     stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit (CVE-2026-43009)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
311692	Linux Distros 未修補的弱點：CVE-2026-43009	Nessus	Misc.	2026/5/2	2026/7/25	high
311692	Linux Distros 未修补的漏洞：CVE-2026-43009	Nessus	Misc.	2026/5/2	2026/7/25	high
318102	openSUSE 16 セキュリティ更新：カーネル (openSUSE-SU-2026:20826-1)	Nessus	SuSE Local Security Checks	2026/6/1	2026/6/2	high
324048	SUSE SLED15:cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc(SUSE-SU-2026:2238-1)	Nessus	SuSE Local Security Checks	2026/7/1	2026/8/4	high
311692	Linux Distros のパッチ未適用の脆弱性: CVE-2026-43009	Nessus	Misc.	2026/5/2	2026/7/25	high
320429	openSUSE 16 セキュリティ更新：カーネル (openSUSE-SU-2026:20912-1)	Nessus	SuSE Local Security Checks	2026/6/11	2026/6/11	medium
318240	SUSE SLES16 セキュリティ更新 : kernel (SUSE-SU-2026:21860-1)	Nessus	SuSE Local Security Checks	2026/6/2	2026/6/9	high
319659	SUSE SLES16 セキュリティ更新 : kernel (SUSE-SU-2026:21845-1)	Nessus	SuSE Local Security Checks	2026/6/8	2026/6/9	high
318102	openSUSE 16 Security Update : kernel (openSUSE-SU-2026:20826-1)	Nessus	SuSE Local Security Checks	2026/6/1	2026/6/2	high
324048	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:2238-1)	Nessus	SuSE Local Security Checks	2026/7/1	2026/8/4	high
331910	Photon OS 5.0: Linux PHSA-2026-5.0-0938	Nessus	PhotonOS Local Security Checks	2026/8/4	2026/8/4	high
311692	Linux Distros Unpatched Vulnerability : CVE-2026-43009	Nessus	Misc.	2026/5/2	2026/7/25	high
320429	openSUSE 16 Security Update : kernel (openSUSE-SU-2026:20912-1)	Nessus	SuSE Local Security Checks	2026/6/11	2026/6/11	medium
323086	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:2482-1)	Nessus	SuSE Local Security Checks	2026/6/26	2026/6/29	high
318240	SUSE SLES16 Security Update : kernel (SUSE-SU-2026:21860-1)	Nessus	SuSE Local Security Checks	2026/6/2	2026/6/9	high
319659	SUSE SLES16 Security Update : kernel (SUSE-SU-2026:21845-1)	Nessus	SuSE Local Security Checks	2026/6/8	2026/6/9	high

检测

插件搜索

high

high

high

high

high

medium

high

high

high

high

high

high

medium

high

high

high