{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2021-47566 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2021-47566 is a high-severity memory corruption vulnerability in Linux kernel, published on 24 May 2024. 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-2021-47566 and fix it if it is affected.\n\nWhat it is: CVE-2021-47566 is a high-severity memory corruption vulnerability in Linux kernel, published on 24 May 2024. 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-2021-47566 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-2021-47566/ (Markdown: https://insights.sbomify.com/CVE-2021-47566/index.md)","id":"CVE-2021-47566","markdown":"https://insights.sbomify.com/CVE-2021-47566/index.md","name":"CVE-2021-47566","record":{"aliases":["DEBIAN-CVE-2021-47566","UBUNTU-CVE-2021-47566"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A local attacker can trigger a kernel crash by copying vmcore data when using a virtio-mem device with unplugged memory blocks.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"nvd","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-787","name":"Out-of-bounds Write"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nproc/vmcore: fix clearing user buffer by properly using clear_user()\n\nTo clear a user buffer we cannot simply use memset, we have to use\nclear_user().  With a virtio-mem device that registers a vmcore_cb and\nhas some logically unplugged memory inside an added Linux memory block,\nI can easily trigger a BUG by copying the vmcore via \"cp\":\n\n  systemd[1]: Starting Kdump Vmcore Save Service...\n  kdump[420]: Kdump is using the default log level(3).\n  kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/\n  kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/\n  kdump[465]: saving vmcore-dmesg.txt complete\n  kdump[467]: saving vmcore\n  BUG: unable to handle page fault for address: 00007f2374e01000\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0003) - permissions violation\n  PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867\n  Oops: 0003 [#1] PREEMPT SMP NOPTI\n  CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86\n  Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 \u003c49\u003e c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81\n  RSP: 0018:ffffc9000073be08 EFLAGS: 00010212\n  RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000\n  RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008\n  RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50\n  R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000\n  R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8\n  FS:  00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0\n  Call Trace:\n   read_vmcore+0x236/0x2c0\n   proc_reg_read+0x55/0xa0\n   vfs_read+0x95/0x190\n   ksys_read+0x4f/0xc0\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nSome x86-64 CPUs have a CPU feature called \"Supervisor Mode Access\nPrevention (SMAP)\", which is used to detect wrong access from the kernel\nto user buffers like this: SMAP triggers a permissions violation on\nwrong access.  In the x86-64 variant of clear_user(), SMAP is properly\nhandled via clac()+stac().\n\nTo fix, properly use clear_user() when we're dealing with a user buffer.","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":"proc/vmcore: fix clearing user buffer by properly using clear_user()","id":"CVE-2021-47566","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"memory_corruption","year":"2021"},"n_packages":0,"n_references":8,"next":{"headline":"powerpc/32: Fix hardlockup on vmap stack overflow","id":"CVE-2021-47567"},"packages":[],"prev":{"headline":"scsi: mpt3sas: Fix kernel panic during drive powercycle test","id":"CVE-2021-47565"},"products":["Linux"],"published":"2024-05-24","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 local attacker can trigger a kernel crash by copying vmcore data when using a virtio-mem device with unplugged memory blocks.","url":"https://insights.sbomify.com/CVE-2021-47566/"}