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+0x146/0x160 fs/xattr.c：617 path_setxattr+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] == uninitialized */ m->rreq = p9_tag_lookup（m->client， m->rc.tag）; /* 递增未初始化的 refcount */ refcount_set（&req->refcount， 2);/* cb 丢弃一个 ref */ p9_client_cb（req） /* 阅读器线程丢弃其 ref： 请求未正确释放
    */ p9_req_put（req） /* 释放后使用和 ref 下溢 */ p9_req_put（req） 要修复此问题，我们可以在添加到 idr 之前将 refcount 初始化为零。（CVE-2022-50335）

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

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/0x160 fs/xattr.c：617 path_setxattr+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 ========================第二個 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 << 搶佔 >> req->tc.tag = tag; /* req->[refcount/tag] == 未初始化 */ m->rreq = p9_tag_lookup（m->client， m->rc.tag）; /* 增加未初始化的參照計數 */ refcount_set（&req->refcount， 2);/* cb 刪除一個 ref */ p9_client_cb（req） /* 讀取器執行緒刪除其 ref： 要求被錯誤釋放
    */ p9_req_put（req） /* 釋放後使用和 ref underflow */ 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 [インライン] 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/0x160 fs/xattr.c:617 path_setxattr+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 ======================== 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] == 初期化されていない */ 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 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.

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.

ID	名前	製品	ファミリー	公開日	更新日	深刻度
264925	Linux Distros 未修补的漏洞：CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/9/30	medium
264925	Linux Distros 未修補弱點：CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/9/30	medium
264925	Linux Distros のパッチ未適用の脆弱性: CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/9/30	medium
264925	Linux Distros Unpatched Vulnerability : CVE-2022-50335	Nessus	Misc.	2025/9/16	2026/9/30	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

検出

プラグインの検索

medium

medium

medium

medium

medium