{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2022-50661 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-50661 is a memory corruption vulnerability in Linux, published on 9 Dec 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-50661 and fix it if it is affected.\n\nWhat it is: CVE-2022-50661 is a memory corruption vulnerability in Linux, published on 9 Dec 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-50661 in the wild and no public exploit code.\n\nAffected product: Linux. 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-50661/ (Markdown: https://insights.sbomify.com/CVE-2022-50661/index.md)","id":"CVE-2022-50661","markdown":"https://insights.sbomify.com/CVE-2022-50661/index.md","name":"CVE-2022-50661","record":{"aliases":["DEBIAN-CVE-2022-50661","GHSA-256c-6mf5-7f9p","UBUNTU-CVE-2022-50661"],"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 local attacker can trigger memory leaks in the Linux kernel seccomp subsystem, potentially leading to resource exhaustion and denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nseccomp: Move copy_seccomp() to no failure path.\n\nOur syzbot instance reported memory leaks in do_seccomp() [0], similar\nto the report [1].  It shows that we miss freeing struct seccomp_filter\nand some objects included in it.\n\nWe can reproduce the issue with the program below [2] which calls one\nseccomp() and two clone() syscalls.\n\nThe first clone()d child exits earlier than its parent and sends a\nsignal to kill it during the second clone(), more precisely before the\nfatal_signal_pending() test in copy_process().  When the parent receives\nthe signal, it has to destroy the embryonic process and return -EINTR to\nuser space.  In the failure path, we have to call seccomp_filter_release()\nto decrement the filter's refcount.\n\nInitially, we called it in free_task() called from the failure path, but\nthe commit 3a15fb6ed92c (\"seccomp: release filter after task is fully\ndead\") moved it to release_task() to notify user space as early as possible\nthat the filter is no longer used.\n\nTo keep the change and current seccomp refcount semantics, let's move\ncopy_seccomp() just after the signal check and add a WARN_ON_ONCE() in\nfree_task() for future debugging.\n\n[0]:\nunreferenced object 0xffff8880063add00 (size 256):\n  comm \"repro_seccomp\", pid 230, jiffies 4294687090 (age 9.914s)\n  hex dump (first 32 bytes):\n    01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................\n    ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................\n  backtrace:\n    do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)\n    do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\nunreferenced object 0xffffc90000035000 (size 4096):\n  comm \"repro_seccomp\", pid 230, jiffies 4294687090 (age 9.915s)\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    __vmalloc_node_range (mm/vmalloc.c:3226)\n    __vmalloc_node (mm/vmalloc.c:3261 (discriminator 4))\n    bpf_prog_alloc_no_stats (kernel/bpf/core.c:91)\n    bpf_prog_alloc (kernel/bpf/core.c:129)\n    bpf_prog_create_from_user (net/core/filter.c:1414)\n    do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)\n    do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\nunreferenced object 0xffff888003fa1000 (size 1024):\n  comm \"repro_seccomp\", pid 230, jiffies 4294687090 (age 9.915s)\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    bpf_prog_alloc_no_stats (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/bpf/core.c:95)\n    bpf_prog_alloc (kernel/bpf/core.c:129)\n    bpf_prog_create_from_user (net/core/filter.c:1414)\n    do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)\n    do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\nunreferenced object 0xffff888006360240 (size 16):\n  comm \"repro_seccomp\", pid 230, jiffies 4294687090 (age 9.915s)\n  hex dump (first 16 bytes):\n    01 00 37 00 76 65 72 6c e0 83 01 06 80 88 ff ff  ..7.verl........\n  backtrace:\n    bpf_prog_store_orig_filter (net/core/filter.c:1137)\n    bpf_prog_create_from_user (net/core/filter.c:1428)\n    do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991)\n    do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\nunreferenced object 0xffff888\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":"seccomp: Move copy_seccomp() to no failure path.","id":"CVE-2022-50661","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2022"},"n_packages":0,"n_references":5,"next":{"headline":"RDMA/hns: fix memory leak in hns_roce_alloc_mr()","id":"CVE-2022-50662"},"packages":[],"prev":{"headline":"wifi: ipw2200: fix memory leak in ipw_wdev_init()","id":"CVE-2022-50660"},"products":["Linux"],"published":"2025-12-09","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A local attacker can trigger memory leaks in the Linux kernel seccomp subsystem, potentially leading to resource exhaustion and denial of service.","url":"https://insights.sbomify.com/CVE-2022-50661/"}