{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-63894 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-63894 is a high-severity use after free vulnerability in Linux, 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-63894 and fix it if it is affected.\n\nWhat it is: CVE-2026-63894 is a high-severity use after free vulnerability in Linux, 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-63894 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-63894/ (Markdown: https://insights.sbomify.com/CVE-2026-63894/index.md)","id":"CVE-2026-63894","markdown":"https://insights.sbomify.com/CVE-2026-63894/index.md","name":"CVE-2026-63894","record":{"aliases":["BELL-CVE-2026-63894","DEBIAN-CVE-2026-63894","GHSA-xh4m-2r9c-xfr3","UBUNTU-CVE-2026-63894"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel USB gadget","requires_auth":"low_privilege","summary":"A use-after-free vulnerability in the Linux kernel USB gadget driver allows attackers to trigger memory corruption or crashes via race conditions during DMABUF operations.","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\nusb: gadget: f_fs: serialize DMABUF cancel against request completion\n\nffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the\ncompleted request but leaves priv-\u003ereq, the back-pointer that\nffs_dmabuf_transfer() set on submission, pointing at the freed\nmemory.  A later FUNCTIONFS_DMABUF_DETACH ioctl or\nffs_epfile_release() on the close path still sees priv-\u003ereq\nnon-NULL under ffs-\u003eeps_lock:\n\n    if (priv-\u003eep \u0026\u0026 priv-\u003ereq)\n            usb_ep_dequeue(priv-\u003eep, priv-\u003ereq);\n\nso usb_ep_dequeue() is called on a freed usb_request.\n\nOn dummy_hcd the dequeue path only walks a live queue and\npointer-compares, so the freed pointer reads without faulting and\nKASAN requires an explicit check at the FunctionFS call site to\nsurface the use-after-free.  On SG-capable in-tree UDCs the\ndequeue path dereferences the supplied request immediately:\n\n  * chipidea's ep_dequeue() does\n    container_of(req, struct ci_hw_req, req) and reads\n    hwreq-\u003ereq.status before acquiring its own lock.\n  * cdnsp's cdnsp_gadget_ep_dequeue() reads request-\u003estatus first.\n\nThe narrower option of clearing priv-\u003ereq via cmpxchg() in the\ncompletion does not close the race: the completion runs without\neps_lock, so a cancel path holding eps_lock can still observe\npriv-\u003ereq non-NULL, race a concurrent completion that clears and\nfrees, and pass the freed pointer to usb_ep_dequeue().  A slightly\nlonger fix that moves the free into the cleanup work is needed.\n\nSame class of lifetime race as the recent usbip-vudc timer fix [1].\n\nTake eps_lock in the sole place that mutates priv-\u003ereq from the\ncallback direction by moving usb_ep_free_request() out of the\ncompletion into ffs_dmabuf_cleanup(), the existing work handler\nscheduled by ffs_dmabuf_signal_done() on\nffs-\u003eio_completion_wq.  Clear priv-\u003ereq there under eps_lock\nbefore freeing, and only clear if priv-\u003ereq still names our\nrequest (a subsequent ffs_dmabuf_transfer() on the same\nattachment may have queued a new one).\n\nThis keeps the existing dummy_hcd sync-dequeue invariant: the\ncompletion callback is still invoked by the UDC without\neps_lock held (dummy_hcd drops its own lock before calling the\ncallback), and the callback now takes no f_fs lock at all.\nSerialization against the cancel path happens in cleanup, which\nruns from the workqueue with no f_fs lock held on entry.\n\nThe priv ref count protects the containing ffs_dmabuf_priv:\nffs_dmabuf_transfer() takes a ref via ffs_dmabuf_get(), cleanup\ndrops it via ffs_dmabuf_put(), so priv stays live for the\ncleanup even after the cancel path's list_del + ffs_dmabuf_put.\n\nThe ffs_dmabuf_transfer() error path no longer frees usb_req\ninline: fence-\u003ereq and fence-\u003eep are set before usb_ep_queue(),\nso ffs_dmabuf_cleanup() (scheduled by the error-path\nffs_dmabuf_signal_done()) owns the free regardless of whether\nthe queue succeeded.\n\nReproduced under KASAN on both detach and close paths against\ndummy_hcd with an observability hook\n(kasan_check_byte(priv-\u003ereq) immediately before usb_ep_dequeue)\nat the two FunctionFS cancel sites to surface the stale-pointer\naccess; the hook is not part of this patch.  The KASAN\nallocator / free stacks in the captured splats identify the\nsame request: alloc in dummy_alloc_request, free in\ndummy_timer, fault reached from ffs_epfile_release (close) and\nfrom the FUNCTIONFS_DMABUF_DETACH ioctl (detach).  With the\npatch applied, both paths are silent under the same hook.\n\nThe bug is reached from the FunctionFS device node, which in\nreal deployments is owned by the privileged gadget daemon\n(adbd, UMS, composite gadget services, etc.); it is not\nreachable from unprivileged userspace or from a USB host on the\ncable.  FunctionFS mounts default to GLOBAL_ROOT_UID, but the\nfilesystem supports uid=, gid=, and fmode= delegation to a\nnon-root gadget daemon, so on real deployments the attacker may\nbe a less-privileged service rather than root.","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":"usb: gadget: f_fs: serialize DMABUF cancel against request completion","id":"CVE-2026-63894","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"use_after_free","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"usb: gadget: f_fs: copy only received bytes on short ep0 read","id":"CVE-2026-63895"},"packages":[],"prev":{"headline":"thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()","id":"CVE-2026-63893"},"products":["Linux"],"published":"2026-07-19","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 use-after-free vulnerability in the Linux kernel USB gadget driver allows attackers to trigger memory corruption or crashes via race conditions during DMABUF operations.","url":"https://insights.sbomify.com/CVE-2026-63894/"}