{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2025-71070 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-71070 is a high-severity use after free vulnerability in Linux, published on 13 Jan 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-2025-71070 and fix it if it is affected.\n\nWhat it is: CVE-2025-71070 is a high-severity use after free vulnerability in Linux, published on 13 Jan 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-2025-71070 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-2025-71070/ (Markdown: https://insights.sbomify.com/CVE-2025-71070/index.md)","id":"CVE-2025-71070","markdown":"https://insights.sbomify.com/CVE-2025-71070/index.md","name":"CVE-2025-71070","record":{"aliases":["BELL-CVE-2025-71070","DEBIAN-CVE-2025-71070","GHSA-p797-qv57-j9x8","UBUNTU-CVE-2025-71070"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel ublk","requires_auth":"low_privilege","summary":"A reference count leak in the Linux kernel ublk driver allows use-after-free conditions when the ublk server exits, potentially leading to code execution or crashes.","user_interaction":"not_required","vuln_class":"use_after_free"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"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":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nublk: clean up user copy references on ublk server exit\n\nIf a ublk server process releases a ublk char device file, any requests\ndispatched to the ublk server but not yet completed will retain a ref\nvalue of UBLK_REFCOUNT_INIT. Before commit e63d2228ef83 (\"ublk: simplify\naborting ublk request\"), __ublk_fail_req() would decrement the reference\ncount before completing the failed request. However, that commit\noptimized __ublk_fail_req() to call __ublk_complete_rq() directly\nwithout decrementing the request reference count.\nThe leaked reference count incorrectly allows user copy and zero copy\noperations on the completed ublk request. It also triggers the\nWARN_ON_ONCE(refcount_read(\u0026io-\u003eref)) warnings in ublk_queue_reinit()\nand ublk_deinit_queue().\nCommit c5c5eb24ed61 (\"ublk: avoid ublk_io_release() called after ublk\nchar dev is closed\") already fixed the issue for ublk devices using\nUBLK_F_SUPPORT_ZERO_COPY or UBLK_F_AUTO_BUF_REG. However, the reference\ncount leak also affects UBLK_F_USER_COPY, the other reference-counted\ndata copy mode. Fix the condition in ublk_check_and_reset_active_ref()\nto include all reference-counted data copy modes. This ensures that any\nublk requests still owned by the ublk server when it exits have their\nreference counts reset to 0.","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":"ublk: clean up user copy references on ublk server exit","id":"CVE-2025-71070","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"use_after_free","year":"2025"},"n_packages":0,"n_references":2,"next":{"headline":"iommu/mediatek: fix use-after-free on probe deferral","id":"CVE-2025-71071"},"packages":[],"prev":{"headline":"f2fs: invalidate dentry cache on failed whiteout creation","id":"CVE-2025-71069"},"products":["Linux"],"published":"2026-01-13","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A reference count leak in the Linux kernel ublk driver allows use-after-free conditions when the ublk server exits, potentially leading to code execution or crashes.","url":"https://insights.sbomify.com/CVE-2025-71070/"}