{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-50396 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-50396 is a medium-severity denial of service vulnerability in Linux kernel, published on 18 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-50396 and fix it if it is affected.\n\nWhat it is: CVE-2022-50396 is a medium-severity denial of service vulnerability in Linux kernel, published on 18 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-50396 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2022-50396/ (Markdown: https://insights.sbomify.com/CVE-2022-50396/index.md)","id":"CVE-2022-50396","markdown":"https://insights.sbomify.com/CVE-2022-50396/index.md","name":"CVE-2022-50396","record":{"aliases":["DEBIAN-CVE-2022-50396","GHSA-8gwc-c833-gwmc","UBUNTU-CVE-2022-50396"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A memory leak in the Linux kernel's traffic control subsystem allows local attackers to exhaust system memory, causing denial of service.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"cisa-adp","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-401","name":"Missing Release of Memory after Effective Lifetime"}],"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    [\u003cffffffff814cf9f0\u003e] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046\n    [\u003cffffffff839c9e07\u003e] kmalloc include/linux/slab.h:576 [inline]\n    [\u003cffffffff839c9e07\u003e] kmalloc_array include/linux/slab.h:627 [inline]\n    [\u003cffffffff839c9e07\u003e] kcalloc include/linux/slab.h:659 [inline]\n    [\u003cffffffff839c9e07\u003e] tcf_exts_init include/net/pkt_cls.h:250 [inline]\n    [\u003cffffffff839c9e07\u003e] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342\n    [\u003cffffffff839caa1f\u003e] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553\n    [\u003cffffffff8394db62\u003e] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147\n    [\u003cffffffff8389e91c\u003e] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082\n    [\u003cffffffff839eba67\u003e] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540\n    [\u003cffffffff839eab87\u003e] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n    [\u003cffffffff839eab87\u003e] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345\n    [\u003cffffffff839eb046\u003e] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921\n    [\u003cffffffff8383e796\u003e] sock_sendmsg_nosec net/socket.c:714 [inline]\n    [\u003cffffffff8383e796\u003e] sock_sendmsg+0x56/0x80 net/socket.c:734\n    [\u003cffffffff8383eb08\u003e] ____sys_sendmsg+0x178/0x410 net/socket.c:2482\n    [\u003cffffffff83843678\u003e] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536\n    [\u003cffffffff838439c5\u003e] __sys_sendmmsg+0x105/0x330 net/socket.c:2622\n    [\u003cffffffff83843c14\u003e] __do_sys_sendmmsg net/socket.c:2651 [inline]\n    [\u003cffffffff83843c14\u003e] __se_sys_sendmmsg net/socket.c:2648 [inline]\n    [\u003cffffffff83843c14\u003e] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648\n    [\u003cffffffff84605fd5\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [\u003cffffffff84605fd5\u003e] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [\u003cffffffff84800087\u003e] 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-\u003eperfect`, 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-\u003eperfect`, or `old_r` is retrieved from `p-\u003eh`.\n\n  * If `old_r` is retrieved from `p-\u003eperfect`, kernel uses\ntcindex_alloc_perfect_hash() to newly allocate the\nfilter results. Then `r` is assigned with `cp-\u003eperfect + handle`,\nwhich is newly allocated. So condition `old_r \u0026\u0026 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-\u003eh`, then `p-\u003eperfect` is NULL\naccording to the tcindex_lookup(). Considering that `cp-\u003eh`\nis directly copied from `p-\u003eh` and `p-\u003eperfect` is NULL,\n`r` is assigned with `tcindex_lookup(cp, handle)`, whose value\nshould be the same as `old_r`, so condition `old_r \u0026\u0026 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-\u003eperfect` 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---","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"net: sched: fix memory leak in tcindex_set_parms","id":"CVE-2022-50396","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2022"},"n_packages":0,"n_references":13,"next":{"headline":"This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.","id":"CVE-2022-50397"},"packages":[],"prev":{"headline":"integrity: Fix memory leakage in keyring allocation error path","id":"CVE-2022-50395"},"products":["Linux"],"published":"2025-09-18","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A memory leak in the Linux kernel's traffic control subsystem allows local attackers to exhaust system memory, causing denial of service.","url":"https://insights.sbomify.com/CVE-2022-50396/"}