{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-49700 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-49700 is a high-severity vulnerability in Linux kernel, published on 26 Feb 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-49700 and fix it if it is affected.\n\nWhat it is: CVE-2022-49700 is a high-severity vulnerability in Linux kernel, published on 26 Feb 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-49700 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-49700/ (Markdown: https://insights.sbomify.com/CVE-2022-49700/index.md)","id":"CVE-2022-49700","markdown":"https://insights.sbomify.com/CVE-2022-49700/index.md","name":"CVE-2022-49700","record":{"aliases":["DEBIAN-CVE-2022-49700","GHSA-p247-4v6m-f77m","UBUNTU-CVE-2022-49700"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","code_execution"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel's SLUB allocator can lead to memory corruption, potentially causing denial of service or arbitrary code execution.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-416","name":"Use After Free"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: add missing TID updates on slab deactivation\n\nThe fastpath in slab_alloc_node() assumes that c-\u003eslab is stable as long as\nthe TID stays the same. However, two places in __slab_alloc() currently\ndon't update the TID when deactivating the CPU slab.\n\nIf multiple operations race the right way, this could lead to an object\ngetting lost; or, in an even more unlikely situation, it could even lead to\nan object being freed onto the wrong slab's freelist, messing up the\n`inuse` counter and eventually causing a page to be freed to the page\nallocator while it still contains slab objects.\n\n(I haven't actually tested these cases though, this is just based on\nlooking at the code. Writing testcases for this stuff seems like it'd be\na pain...)\n\nThe race leading to state inconsistency is (all operations on the same CPU\nand kmem_cache):\n\n - task A: begin do_slab_free():\n    - read TID\n    - read pcpu freelist (==NULL)\n    - check `slab == c-\u003eslab` (true)\n - [PREEMPT A-\u003eB]\n - task B: begin slab_alloc_node():\n    - fastpath fails (`c-\u003efreelist` is NULL)\n    - enter __slab_alloc()\n    - slub_get_cpu_ptr() (disables preemption)\n    - enter ___slab_alloc()\n    - take local_lock_irqsave()\n    - read c-\u003efreelist as NULL\n    - get_freelist() returns NULL\n    - write `c-\u003eslab = NULL`\n    - drop local_unlock_irqrestore()\n    - goto new_slab\n    - slub_percpu_partial() is NULL\n    - get_partial() returns NULL\n    - slub_put_cpu_ptr() (enables preemption)\n - [PREEMPT B-\u003eA]\n - task A: finish do_slab_free():\n    - this_cpu_cmpxchg_double() succeeds()\n    - [CORRUPT STATE: c-\u003eslab==NULL, c-\u003efreelist!=NULL]\n\nFrom there, the object on c-\u003efreelist will get lost if task B is allowed to\ncontinue from here: It will proceed to the retry_load_slab label,\nset c-\u003eslab, then jump to load_freelist, which clobbers c-\u003efreelist.\n\nBut if we instead continue as follows, we get worse corruption:\n\n - task A: run __slab_free() on object from other struct slab:\n    - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)\n - task A: run slab_alloc_node() with NUMA node constraint:\n    - fastpath fails (c-\u003eslab is NULL)\n    - call __slab_alloc()\n    - slub_get_cpu_ptr() (disables preemption)\n    - enter ___slab_alloc()\n    - c-\u003eslab is NULL: goto new_slab\n    - slub_percpu_partial() is non-NULL\n    - set c-\u003eslab to slub_percpu_partial(c)\n    - [CORRUPT STATE: c-\u003eslab points to slab-1, c-\u003efreelist has objects\n      from slab-2]\n    - goto redo\n    - node_match() fails\n    - goto deactivate_slab\n    - existing c-\u003efreelist is passed into deactivate_slab()\n    - inuse count of slab-1 is decremented to account for object from\n      slab-2\n\nAt this point, the inuse count of slab-1 is 1 lower than it should be.\nThis means that if we free all allocated objects in slab-1 except for one,\nSLUB will think that slab-1 is completely unused, and may free its page,\nleading to use-after-free.","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":"mm/slub: add missing TID updates on slab deactivation","id":"CVE-2022-49700","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2022"},"n_packages":0,"n_references":8,"next":{"headline":"scsi: ibmvfc: Allocate/free queue resource only during probe/remove","id":"CVE-2022-49701"},"packages":[],"prev":{"headline":"filemap: Handle sibling entries in filemap_get_read_batch()","id":"CVE-2022-49699"},"products":["Linux"],"published":"2025-02-26","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":"total"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A race condition in the Linux kernel's SLUB allocator can lead to memory corruption, potentially causing denial of service or arbitrary code execution.","url":"https://insights.sbomify.com/CVE-2022-49700/"}