{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-90424 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-90424 is a memory corruption vulnerability in Linux, published on 17 Sep 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-90424 and fix it if it is affected.\n\nWhat it is: CVE-2026-90424 is a memory corruption vulnerability in Linux, published on 17 Sep 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-90424 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-2026-90424/ (Markdown: https://insights.sbomify.com/CVE-2026-90424/index.md)","id":"CVE-2026-90424","markdown":"https://insights.sbomify.com/CVE-2026-90424/index.md","name":"CVE-2026-90424","record":{"aliases":["BELL-CVE-2026-90424","DEBIAN-CVE-2026-90424","GHSA-f39c-j3gp-39r5","UBUNTU-CVE-2026-90424"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"none","summary":"A memory leak in the Linux kernel Tegra241 IOMMU driver can lead to resource exhaustion and denial of service during initialization failures.","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\niommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path\n\ntegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits\nit, and preallocates its logical VCMDQs. Two of its error paths leak.\n\nWhen tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the\ncmdqv-\u003evintfs[] array, so the devres unwind on probe failure cannot reach\nit; free it directly there.\n\nA later VCMDQ preallocation failure instead leaves VINTF0 published, and so\nthis time the unwind does reach tegra241_cmdqv_remove_vintf(), which then\nfrees it from vintf-\u003ehyp_own. But tegra241_vintf_hw_init() sets that flag\nonly afterward, from a HW read-back, so the still-uninited VINTF0 reads as\nguest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields\nit never set up.\n\nDecide ownership from vintf-\u003eidx instead, the index assigned when its id is\nallocated: idx 0 is the kernel-owned VINTF0, while idx \u003e= 1 marks a guest\nVINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and\ntegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure\nHW-readback state.","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":"iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path","id":"CVE-2026-90424","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID","id":"CVE-2026-90425"},"packages":[],"prev":{"headline":"RDMA/rxe: Fix UAF in ODP init error-handling path","id":"CVE-2026-90423"},"products":["Linux"],"published":"2026-09-17","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-10-21","vendors":["Linux"]},"summary":"A memory leak in the Linux kernel Tegra241 IOMMU driver can lead to resource exhaustion and denial of service during initialization failures.","url":"https://insights.sbomify.com/CVE-2026-90424/"}