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

  - 9p将 req refcount 设置为零以避免未初始化的使用。分配新请求时如果重新使用 refcount 将会为零但如果该请求是从 slab 中新分配的则在被添加到 idr 之前不会完全初始化。p9_read_work 是否在引用计数启动之前得到响应。它将使用未初始化的 req从而导致错误的请求数据结构。以下是来自 syzbot 的日志。位于 0xffff88807eade00b 的内存损坏 [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 。 。 。 。 。 。 。 。 ] 中 kfence-#110
    p9_fcall_fini net/9p/client.c:248 [内联] p9_req_put net/9p/client.c:396 [内联] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client .c:1165 clone_fid fs/9p/fid.h:21 [内联] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [内联] v9fs_xattr_handler_set+0x6f/0x120 fs /9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
    __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x1attr+c:309 setxattr+0x146/0x1attr+c:609 0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [内联] __se_sys_setxattr fs/xattr.c:648 [内联]
    __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [内联]
    __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 以下是类似的情况syzbot 日志中的情况看起来比这个问题更复杂但此修补程序可对其进行修复。 T21124 p9_read_work ======================== 第二个事务 ===================== ============ p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == 未初始化 */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* 递增未初始化的 refcount */ refcount_set(&req->refcount, 2); /* cb 丢弃一个 ref */ p9_client_cb(req) /* reader 线程丢弃其 ref 请求被错误地释放
    */ p9_req_put(req) /* 释放后使用和引用下溢 */ p9_req_put(req) 要修复此问题可在添加到 idr 之前将 refcount 初始化为零。 (CVE-2022-50335)

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

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

  - 9p將 req refcount 設為零以避免未初始化的使用方式配置新要求時若重複使用 refcount 將會為零但是如果要求是從 slab 新配置則在新增至 idr 之前該要求未完全初始化。如果 p9_read_work 在啟動 refcount 前收到回應。它將使用未初始化的 req這將導致錯誤的要求資料結構。以下是來自 syzbot 的記錄。0xffff88807eade00b 的記憶體損毀 [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 。 。 。 。 。 。 。 。 ] (在 kfence-#110中)
    p9_fcall_fini net/9p/client.c:248 [內嵌] p9_req_put net/9p/client.c:396 [內嵌] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client .c:1165 clone_fid fs/9p/fid.h:21 [內嵌] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [內嵌] v9fs_xattr_handler_set+0x6f/0x120 fs /9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
    __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0xattr146/0x1670 path_xattr+61 0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [內嵌] __se_sys_setxattr fs/xattr.c:648 [內嵌]
    __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [內嵌]
    __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 以下是類似的狀況，syzbot 記錄中的狀況看起來比此問題更複雜不過此修補程式可修正此問題。 T21124 p9_read_work ======================== 第二次傳輸 ===================== ============ p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == 未初始化 */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* 遞增未初始化的 refcount */ refcount_set(&req->refcount, 2); /* cb 中斷一個參照 */ p9_client_cb(req) /* 讀取器執行緒中斷其參照要求未正確釋放
    */ p9_req_put(req) /* 釋放後使用和 ref 反向溢位 */ p9_req_put(req) 若要修正此問題我們可以在新增到 idr 之前將 refcount 初始化為零。 (CVE-2022-50335)

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

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

  - 9p初期化されていない使用を回避するために req refcount をゼロに設定します。新しいリクエストが割り当てられている場合、再利用されると refcount はゼロになります。ただし、リクエストがスラブから新たに割り当てられる場合、idr に追加される前に完全に初期化されません。refcount が開始される前に p9_read_work が応答を取得した場合。初期化されていない req を使用するため、リクエストデータ構造が無効になります。syzbot からのログです。0xffff88807eade00b でのメモリ破損 [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 。 。 。 。 。 。 。 。 kfence-#110の中
    p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client .c:1165 clone_fid fs/9p/fid.h:21 [インライン] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [インライン] v9fs_xattr_handler_set+0x6f/0x120 fs /9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
    __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 path:6attr.c:309 setxattr+0x146/0xtr.c:309 setxattr+0x146/0x160 path: 0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [インライン] __se_sys_setxattr fs/xattr.c:648 [インライン]
    __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [インライン]
    __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 以下は類似のシナリオです。syzbotログのシナリオは同様のシナリオです。これはこれよりも複雑ですが、このパッチで修正できます。 T21124 p9_read_work =================================================== ============== p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == 初期化されていない */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* 初期化されていない refcount をインクリメントします */ refcount_set(&req->refcount, 2); /* cb が 1 つの ref をドロップします */ p9_client_cb(req) /* リーダースレッドが ref をドロップしますリクエストが不適切に解放されます
    */ p9_req_put(req) /* use-after-free および ref アンダーフロー */ p9_req_put(req) これを修正するために、idr に追加する前に refcount をゼロに初期化できます。CVE-2022-50335

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-021528 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    9p: set req refcount to zero to avoid uninitialized usage

    When a new request is allocated, the refcount will be zero if it is     reused, but if the request is newly allocated from slab, it is not fully     initialized before being added to idr.

    If the p9_read_work got a response before the refcount initiated. It will     use a uninitialized req, which will result in a bad request data struct.

    Here is the logs from syzbot.

    Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00     0x00 0x00 . . . . . . . . ] (in kfence-#110):
     p9_fcall_fini net/9p/client.c:248 [inline]      p9_req_put net/9p/client.c:396 [inline]      p9_req_put+0x208/0x250 net/9p/client.c:390      p9_client_walk+0x247/0x540 net/9p/client.c:1165      clone_fid fs/9p/fid.h:21 [inline]      v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118      v9fs_xattr_set fs/9p/xattr.c:100 [inline]      v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159
     __vfs_setxattr+0x119/0x180 fs/xattr.c:182
     __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216
     __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277      vfs_setxattr+0x143/0x340 fs/xattr.c:309      setxattr+0x146/0x160 fs/xattr.c:617      path_setxattr+0x197/0x1c0 fs/xattr.c:636
     __do_sys_setxattr fs/xattr.c:652 [inline]
     __se_sys_setxattr fs/xattr.c:648 [inline]
     __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648      do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178      do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203      entry_SYSENTER_compat_after_hwframe+0x70/0x82

    Below is a similar scenario, the scenario in the syzbot log looks more     complicated than this one, but this patch can fix it.

         T21124                   p9_read_work     ======================== second trans =================================     p9_client_walk       p9_client_rpc         p9_client_prepare_req           p9_tag_alloc             req = kmem_cache_alloc(p9_req_cache, GFP_NOFS);
            tag = idr_alloc             << preempted >>             req->tc.tag = tag;
                                /* req->[refcount/tag] == uninitialized */                                 m->rreq = p9_tag_lookup(m->client, m->rc.tag);
                                  /* increments uninitalized refcount */

            refcount_set(&req->refcount, 2);
                                /* cb drops one ref */                                 p9_client_cb(req)                                 /* reader thread drops its ref:
                                   request is incorrectly freed */                                 p9_req_put(req)         /* use after free and ref underflow */         p9_req_put(req)

    To fix it, we can initialize the refcount to zero before add to idr.

Tenable has extracted the preceding description block directly from the Unity Linux 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.

  - 9p: set req refcount to zero to avoid uninitialized usage When a new request is allocated, the refcount     will be zero if it is reused, but if the request is newly allocated from slab, it is not fully initialized     before being added to idr. If the p9_read_work got a response before the refcount initiated. It will use a     uninitialized req, which will result in a bad request data struct. Here is the logs from syzbot. Corrupted     memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00 0x00 0x00 . . . . . . . . ] (in kfence-#110):
    p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250     net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline]     v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline]     v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182
    __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277     vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0     fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline]
    __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
    __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70     arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Below is a similar scenario, the     scenario in the syzbot log looks more complicated than this one, but this patch can fix it. T21124     p9_read_work ======================== second trans ================================= p9_client_walk     p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag =     idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq =     p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount,     2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed
    */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req) To fix it, we can initialize the     refcount to zero before add to idr. (CVE-2022-50335)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
264925	Linux Distros 未修补的漏洞：CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/7/17	medium
264925	Linux Distros 未修補的弱點：CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/7/17	medium
264925	Linux Distros のパッチ未適用の脆弱性: CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/7/17	medium
315893	Unity Linux 20.1050e Security Update: kernel (UTSA-2026-021528)	Nessus	Unity Linux Local Security Checks	2026/5/20	2026/5/20	medium
264925	Linux Distros Unpatched Vulnerability : CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/7/17	medium

检测

插件搜索

medium

medium

medium

medium

medium