FKIE_CVE-2026-63894

Vulnerability from fkie_nvd - Published: 2026-07-19 16:17 - Updated: 2026-07-27 17:44
Severity
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: serialize DMABUF cancel against request completion ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the completed request but leaves priv->req, the back-pointer that ffs_dmabuf_transfer() set on submission, pointing at the freed memory. A later FUNCTIONFS_DMABUF_DETACH ioctl or ffs_epfile_release() on the close path still sees priv->req non-NULL under ffs->eps_lock: if (priv->ep && priv->req) usb_ep_dequeue(priv->ep, priv->req); so usb_ep_dequeue() is called on a freed usb_request. On dummy_hcd the dequeue path only walks a live queue and pointer-compares, so the freed pointer reads without faulting and KASAN requires an explicit check at the FunctionFS call site to surface the use-after-free. On SG-capable in-tree UDCs the dequeue path dereferences the supplied request immediately: * chipidea's ep_dequeue() does container_of(req, struct ci_hw_req, req) and reads hwreq->req.status before acquiring its own lock. * cdnsp's cdnsp_gadget_ep_dequeue() reads request->status first. The narrower option of clearing priv->req via cmpxchg() in the completion does not close the race: the completion runs without eps_lock, so a cancel path holding eps_lock can still observe priv->req non-NULL, race a concurrent completion that clears and frees, and pass the freed pointer to usb_ep_dequeue(). A slightly longer fix that moves the free into the cleanup work is needed. Same class of lifetime race as the recent usbip-vudc timer fix [1]. Take eps_lock in the sole place that mutates priv->req from the callback direction by moving usb_ep_free_request() out of the completion into ffs_dmabuf_cleanup(), the existing work handler scheduled by ffs_dmabuf_signal_done() on ffs->io_completion_wq. Clear priv->req there under eps_lock before freeing, and only clear if priv->req still names our request (a subsequent ffs_dmabuf_transfer() on the same attachment may have queued a new one). This keeps the existing dummy_hcd sync-dequeue invariant: the completion callback is still invoked by the UDC without eps_lock held (dummy_hcd drops its own lock before calling the callback), and the callback now takes no f_fs lock at all. Serialization against the cancel path happens in cleanup, which runs from the workqueue with no f_fs lock held on entry. The priv ref count protects the containing ffs_dmabuf_priv: ffs_dmabuf_transfer() takes a ref via ffs_dmabuf_get(), cleanup drops it via ffs_dmabuf_put(), so priv stays live for the cleanup even after the cancel path's list_del + ffs_dmabuf_put. The ffs_dmabuf_transfer() error path no longer frees usb_req inline: fence->req and fence->ep are set before usb_ep_queue(), so ffs_dmabuf_cleanup() (scheduled by the error-path ffs_dmabuf_signal_done()) owns the free regardless of whether the queue succeeded. Reproduced under KASAN on both detach and close paths against dummy_hcd with an observability hook (kasan_check_byte(priv->req) immediately before usb_ep_dequeue) at the two FunctionFS cancel sites to surface the stale-pointer access; the hook is not part of this patch. The KASAN allocator / free stacks in the captured splats identify the same request: alloc in dummy_alloc_request, free in dummy_timer, fault reached from ffs_epfile_release (close) and from the FUNCTIONFS_DMABUF_DETACH ioctl (detach). With the patch applied, both paths are silent under the same hook. The bug is reached from the FunctionFS device node, which in real deployments is owned by the privileged gadget daemon (adbd, UMS, composite gadget services, etc.); it is not reachable from unprivileged userspace or from a USB host on the cable. FunctionFS mounts default to GLOBAL_ROOT_UID, but the filesystem supports uid=, gid=, and fmode= delegation to a non-root gadget daemon, so on real deployments the attacker may be a less-privileged service rather than root.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2796646f6d892c1eb6818c7ca41fdfa12568e8d1
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/552dae28dbeb5f7c4fafcda43962dc46569f58a0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c7d421123b98d5e9c1c84bd9957aba36f1cbb4ca
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c872d8a065b3b499ce4c3ad168b5d34b68524f66
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/usb/gadget/function/f_fs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c872d8a065b3b499ce4c3ad168b5d34b68524f66",
              "status": "affected",
              "version": "7b07a2a7ca02a20124b552be96c5a56910795488",
              "versionType": "git"
            },
            {
              "lessThan": "c7d421123b98d5e9c1c84bd9957aba36f1cbb4ca",
              "status": "affected",
              "version": "7b07a2a7ca02a20124b552be96c5a56910795488",
              "versionType": "git"
            },
            {
              "lessThan": "552dae28dbeb5f7c4fafcda43962dc46569f58a0",
              "status": "affected",
              "version": "7b07a2a7ca02a20124b552be96c5a56910795488",
              "versionType": "git"
            },
            {
              "lessThan": "2796646f6d892c1eb6818c7ca41fdfa12568e8d1",
              "status": "affected",
              "version": "7b07a2a7ca02a20124b552be96c5a56910795488",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/usb/gadget/function/f_fs.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.9"
            },
            {
              "lessThan": "6.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.93",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.35",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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\u0027s 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\u0027s 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\u0027s 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."
    }
  ],
  "id": "CVE-2026-63894",
  "lastModified": "2026-07-27T17:44:23.777",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-07-19T16:17:06.850",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2796646f6d892c1eb6818c7ca41fdfa12568e8d1"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/552dae28dbeb5f7c4fafcda43962dc46569f58a0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c7d421123b98d5e9c1c84bd9957aba36f1cbb4ca"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c872d8a065b3b499ce4c3ad168b5d34b68524f66"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.