In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
usb: gadget: f_fs: serialize DMABUF cancel against request completion<\/p>\n
ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() on the
\ncompleted request but leaves priv->req, 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->req
\nnon-NULL under ffs->eps_lock:<\/p>\n
if (priv->ep && priv->req)
\n usb_ep_dequeue(priv->ep, priv->req);<\/p>\n
so usb_ep_dequeue() is called on a freed usb_request.<\/p>\n
On 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:<\/p>\n
* chipidea’s ep_dequeue() does
\n container_of(req, struct ci_hw_req, req) and reads
\n hwreq->req.status before acquiring its own lock.
\n * cdnsp’s cdnsp_gadget_ep_dequeue() reads request->status first.<\/p>\n
The narrower option of clearing priv->req 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->req 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.<\/p>\n
Same class of lifetime race as the recent usbip-vudc timer fix [1].<\/p>\n
Take eps_lock in the sole place that mutates priv->req 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->io_completion_wq. Clear priv->req there under eps_lock
\nbefore freeing, and only clear if priv->req still names our
\nrequest (a subsequent ffs_dmabuf_transfer() on the same
\nattachment may have queued a new one).<\/p>\n
This 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.<\/p>\n
The 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.<\/p>\n
The ffs_dmabuf_transfer() error path no longer frees usb_req
\ninline: fence->req and fence->ep 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.<\/p>\n
Reproduced under KASAN on both detach and close paths against
\ndummy_hcd with an observability hook
\n(kasan_check_byte(priv->req) 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.<\/p>\n
The 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
usb: gadget: f_fs: serialize DMABUF cancel against request completion<\/p>\n
ffs_epfile_dmabuf_io_complete() calls usb_ep_free_request() <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-14945","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/14945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=14945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=14945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=14945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}