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

  - net: sched: fix memory leak in tcindex_set_parms Syzkaller reports a memory leak as follows:
    ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256):
    comm syz-executor105, pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00     00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046     [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff839c9e07>] kmalloc_array     include/linux/slab.h:627 [inline] [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]     [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>]     tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120     net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147     [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>]     netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel     net/netlink/af_netlink.c:1319 [inline] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0     net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710     net/netlink/af_netlink.c:1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]     [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110     net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648     [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>]     do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0     arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd     ==================================== Kernel uses tcindex_change() to change an existing filter properties.
    Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then     kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses     tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure,     which triggers the above memory leak. To be more specific, there are only two source for the `old_r`,     according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from     `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly     allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated.
    So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init()     to clear the old filter result, without destroying its tcf_exts structure * If `old_r` is retrieved from     `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly     copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose     value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel     ignores using tcindex_filter_result_init() to clear the old filter result. So only when `old_r` is     retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result,     which triggers the above memory leak. Considering that there already exists a tc_filter_wq workqueue to     destroy the old tcindex_d ---truncated--- (CVE-2022-50396)

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

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

  - netsched修复 tcindex_set_parms 中的内存泄漏 Syzkaller 报告内存泄漏如下
    ==================================== 缺陷内存泄漏未引用对象 0xffff88810c287f00大小 256
    comm syz-executor105、pid 3600、jiffies 4294943292(age 12.990s) 十六进制转储前 32 字节00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. ...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ......回溯[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [内联] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [内联] [<ffffffff839c9e07>] kcalloc include/linux/slab。 h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb +0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [内联] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c 1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [内联] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86 /entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ========== ========================== 内核使用 tcindex_change() 更改现有过滤器属性。
    但问题是在更改过程中如果从“p->perfect”检索“old_r”则内核使用 tcindex_alloc_perfect_hash() 重新分配筛选结果使用 tcindex_filter_result_init() 清除旧筛选结果而不需要破坏其 tcf_exts 结构从而触发上述内存泄漏。更具体地说，根据 tcindex_lookup()，“old_r”只有两个来源。是从“p->perfect”检索“old_r”或从“p->h”检索“old_r”。 * 如果从 `p->perfect` 检索 `old_r`内核使用 tcindex_alloc_perfect_hash() 重新分配过滤器结果。然后为新分配的“cp->perfect + handle”分配“r”。
    因此这种情况下条件 `old_r && old_r != r` 为真内核使用 tcindex_filter_result_init() 清除旧过滤结果而不会破坏其 tcf_exts 结构 * 如果从 `p->h` 中检索 `old_r`则根据 tcindex_lookup()“p->perfect”为空。考虑到“cp->h”是直接从“p->h”复制并且“p->perfect”为空向“r”分配“tcindex_lookup(cp, handle)”其值应与 相同“old_r”因此在这种情况下条件“old_r && old_r != r”为假内核会忽略使用 tcindex_filter_result_init() 清除旧过滤结果。因此仅当从“p->perfect”检索“old_r”时内核才会使用 tcindex_filter_result_init() 清除旧的过滤结果这会触发上述内存泄漏。考虑已存在 tc_filter_wq 工作队列破坏旧的 tcindex_d ---truncated--- (CVE-2022-50396)

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

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

  - netschedtcindex_set_parms のメモリリークを修正します Syzkaller は次のようにメモリリークを報告します
    ==================================================================================================== バグ
    comm syz-executor105、pid 3600、jiffies 4294943292 (age 12.990s) hex dump最初の 32 バイト00 00 00 00 00 00 00 00 00 00 00 00 00 0000000000000000000000000000000000000000000000000000000 ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 内のバックトレース[<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [インライン] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [インライン] [<ffffffff839c9e07>] kcalloc include/linux/slab. h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082<ffffffff839eba67>] netlink_rcv_skb +0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [インライン] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [[<ffffffff839eb046>] ] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c :1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    __sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] __sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86 /entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd =============== ============================ カーネルは tcindex_change() を使用して、既存のフィルタープロパティを変更します。
    問題は、変更のプロセス中に「old_r」が「p->perfect」から取得されると、カーネルが tcindex_alloc_performance_hash() を使用してフィルター結果を新たに割り当て、tcindex_filter_result_init() を使用して古いフィルター結果をクリアせず、その tcf_exts 構造体を破壊し、上記のメモリリークを発生させます。より具体的には、tcindex_lookup() によると、「old_r」には 2 つのソースのみがあります。 「old_r」は「p->performance」から取得されるか、「old_r」は「p->h」から取得されます。 * 「old_r」が「p->complete」から取得されると、カーネルは tcindex_alloc_performance_hash() を使用し、フィルター結果を新たに割り当てます。次に「r」が「cp->perfect + handle」で割り当てられ、これは新たに割り当てられます。
    そのため、条件「old_r && old_r != r」はこの状況で真であり、カーネルは tcindex_filter_result_init() を使用して、tcf_exts 構造を破壊せずに、古いフィルター結果をクリアします。* 「old_r」が「p->h」から取得される場合、 「p->perfect」は、tcindex_lookup() によると NULL です。「cp->h」が「p->h」から直接コピーされ、「p->performance」が NULL であることを考慮すると、「r」は「tcindex_lookup(cp, handle)」で割り当てられ、その値は と同じでなければなりません。 「old_r」が「old_r && old_r != r」となるため、カーネルは tcindex_filter_result_init() を使用して古いフィルター結果をクリアすることを無視します。そのため、「old_r」が「p->complete」から取得されるときのみ、カーネルは tcindex_filter_result_init() を使用して古いフィルターの結果をクリアし、これが上記のメモリリークを発生させます。古い tcindex_d を破壊する tc_filter_wq 作業キューがすでに存在することを考慮 ---truncated---CVE-2022-50396

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

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

  - netsched修正 tcindex_set_parms 中的記憶體洩漏 Syzkaller 報告如下記憶體洩漏
    ==================================== 錯誤記憶體洩漏未參照物件 0xffff88810c287f00 (大小 256)
    comm syz-executor105、pid 3600、jiffies 4294943292 (12.990s 時效) 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 反向追踪 [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [內嵌] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [內嵌] [<ffffffff839c9e07>] kcalloc include/linux/slab。 h:659 [內嵌] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [內嵌] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb +0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [內嵌] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c :1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [內嵌] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [內嵌] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [內嵌] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86 /entry/common.c:50 [內嵌] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ========== ========================== 核心使用 tcindex_change() 變更現有的篩選內容。
    然而問題在於在變更的過程中若從「p->perfect」擷取「old_r」則核心會使用 tcindex_alloc_perfect_hash() 來新配置篩選結果使用 tcindex_filter_result_init() 清除舊的篩選結果破壞其 tcf_exts 結構進而觸發上述記憶體洩漏。根據 tcindex_lookup() 的說明確切地說「old_r」只有兩個來源。 `old_r` 是從 `p->perfect` 擷取或 `old_r` 是從 `p->h` 擷取。 * 如果是從 `p->perfect` 擷取 `old_r`核心會使用 tcindex_alloc_perfect_hash() 來新配置篩選結果。然後 `r` 會以新配置的 `cp->perfect + handle` 指派。
    因此條件 `old_r && old_r != r` 在此情況下為 true且核心會使用 tcindex_filter_result_init() 清除舊的篩選結果而不損毀其 tcf_exts 結構 * 如果是從 `p->h` 擷取 `old_r`則根據 tcindex_lookup()「p->perfect」為 NULL。考慮到 `cp->h` 是直接從 `p->h` 複製且 `p->perfect` 為 NULL因此 `r` 會指派 `tcindex_lookup(cp, handle)`其值應與 相同`old_r`因此 `old_r && old_r != r` 條件在此情況下為假核心會忽略使用 tcindex_filter_result_init() 清除舊篩選結果的過程。因此只有當從 `p->perfect` 擷取 `old_r` 時核心才會使用 tcindex_filter_result_init() 清除舊的篩選結果進而觸發上述記憶體洩漏。考慮到已經存在 tc_filter_wq 工作佇列可以損毀舊的 tcindex_d ---truncated--- (CVE-2022-50396)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
265574	Linux Distros Unpatched Vulnerability : CVE-2022-50396	Nessus	Misc.	2025/9/19	2025/9/29	medium
265574	Linux Distros 未修补的漏洞：CVE-2022-50396	Nessus	Misc.	2025/9/19	2025/9/29	medium
265574	Linux Distros のパッチ未適用の脆弱性: CVE-2022-50396	Nessus	Misc.	2025/9/19	2025/9/29	medium
265574	Linux Distros 未修補的弱點：CVE-2022-50396	Nessus	Misc.	2025/9/19	2025/9/29	medium

偵測

搜尋 Plugin

medium

medium

medium

medium