{"cve":"CVE-2022-50396","nvd":{"published":"2025-09-18T14:15:38.737","modified":"2026-06-17T05:23:26.860","status":"Modified","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix memory leak in tcindex_set_parms\n\nSyzkaller reports a memory leak as follows:\n====================================\nBUG: memory leak\nunreferenced object 0xffff88810c287f00 (size 256):\n  comm \"syz-executor105\", pid 3600, jiffies 4294943292 (age 12.990s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046\n    [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]\n    [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]\n    [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]\n    [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]\n    [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342\n    [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553\n    [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147\n    [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082\n    [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540\n    [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n    [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345\n    [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921\n    [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]\n    [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734\n    [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482\n    [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536\n    [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622\n    [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]\n    [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]\n    [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648\n    [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n====================================\n\nKernel uses tcindex_change() to change an existing\nfilter properties.\n\nYet the problem is that, during the process of changing,\nif `old_r` is retrieved from `p->perfect`, then\nkernel uses tcindex_alloc_perfect_hash() to newly\nallocate filter results, uses tcindex_filter_result_init()\nto clear the old filter result, without destroying\nits tcf_exts structure, which triggers the above memory leak.\n\nTo be more specific, there are only two source for the `old_r`,\naccording to the tcindex_lookup(). `old_r` is retrieved from\n`p->perfect`, or `old_r` is retrieved from `p->h`.\n\n  * If `old_r` is retrieved from `p->perfect`, kernel uses\ntcindex_alloc_perfect_hash() to newly allocate the\nfilter results. Then `r` is assigned with `cp->perfect + handle`,\nwhich is newly allocated. So condition `old_r && old_r != r` is\ntrue in this situation, and kernel uses tcindex_filter_result_init()\nto clear the old filter result, without destroying\nits tcf_exts structure\n\n  * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL\naccording to the tcindex_lookup(). Considering that `cp->h`\nis directly copied from `p->h` and `p->perfect` is NULL,\n`r` is assigned with `tcindex_lookup(cp, handle)`, whose value\nshould be the same as `old_r`, so condition `old_r && old_r != r`\nis false in this situation, kernel ignores using\ntcindex_filter_result_init() to clear the old filter result.\n\nSo only when `old_r` is retrieved from `p->perfect` does kernel use\ntcindex_filter_result_init() to clear the old filter result, which\ntriggers the above memory leak.\n\nConsidering that there already exists a tc_filter_wq workqueue\nto destroy the old tcindex_d\n---truncated---","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-401"],"references":["https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b","https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6","https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd","https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7","https://git.kernel.org/stable/c/3abebc503a5148072052c229c6b04b329a420ecd"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:10:08.713834912+00:00"},"epss":{"cve":"CVE-2022-50396","score":0.00174,"percentile":0.06867,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}