{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-63941 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-63941 is a high-severity vulnerability in Linux kernel, published on 19 Jul 2026. 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-2026-63941 and fix it if it is affected.\n\nWhat it is: CVE-2026-63941 is a high-severity vulnerability in Linux kernel, published on 19 Jul 2026. 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-2026-63941 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-2026-63941/ (Markdown: https://insights.sbomify.com/CVE-2026-63941/index.md)","id":"CVE-2026-63941","markdown":"https://insights.sbomify.com/CVE-2026-63941/index.md","name":"CVE-2026-63941","record":{"aliases":["BELL-CVE-2026-63941","DEBIAN-CVE-2026-63941","GHSA-9mxh-6wp4-9v6p","ROOT-OS-DEBIAN-13-CVE-2026-63941","UBUNTU-CVE-2026-63941"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["privilege_escalation","code_execution"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel KVM","requires_auth":"low_privilege","summary":"A guest hypervisor can bypass vector length restrictions in KVM arm64, potentially allowing an L2 guest to access unauthorized hardware resources or escalate privileges.","user_interaction":"not_required","vuln_class":"privilege_escalation"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":8.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-862","name":"Missing Authorization"},{"id":"CWE-20","name":"Improper Input Validation"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor\n\nZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2\n(which traps) or ZCR_EL1 (which does not trap). KVM handles both in\ndifferent way:\n\n- on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM's own\n  VL limit. This has the potential to break existing SW that relies\n  on the full LEN field to be stateful.\n\n- on ZCR_EL1 access, we do absolutely nothing.\n\nOn restoring the SVE context for an L2 guest, we directly restore the\nguest hypervisor's view of ZCR_EL2 into the physical ZCR_EL2. If the\nguest's view of the register was updated using the ZCR_EL2 accessor,\nthe value has already been sanitised (with the caveat mentioned above).\n\nBut if the guest used ZCR_EL1, the raw value is written into the HW,\nand the L2 guest can now access VLs that it shouldn't.\n\nFix all the above by moving the VL capping to the restore points,\nensuring that:\n\n- the HW is always programmed with a capped value, irrespective of\n  the accessor being used,\n\n- the ZCR_EL2.LEN field is always completely stateful, irrespective\n  of the accessor being used.\n\nAdditionally, move ZCR_EL2 to be a sanitised register, ensuring that\nonly the LEN field is actually stateful. This requires some creative\nconstruction of the RES0 mask, as the sysreg generation script does\nnot yet generate RAZ/WI fields.\n\n[maz: rewrote commit message, tidy up access_zcr_el2()]","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":"KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor","id":"CVE-2026-63941","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"privilege_escalation","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"parport: Fix race between port and client registration","id":"CVE-2026-63942"},"packages":[],"prev":{"headline":"KVM: SEV: Ignore Port I/O requests of length '0'","id":"CVE-2026-63940"},"products":["Linux"],"published":"2026-07-19","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-10-19","vendors":["Linux"]},"summary":"A guest hypervisor can bypass vector length restrictions in KVM arm64, potentially allowing an L2 guest to access unauthorized hardware resources or escalate privileges.","url":"https://insights.sbomify.com/CVE-2026-63941/"}