Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Refcount underflow and use-after-free of obj_cgroup due to shallow copy in ghost objects. --
commit 0958e13ef29f184401c5e0dda949311750032e9b Author: Dave Airlie <[email protected]> ttm: add objcg pointer to bo and tt (v2) This commit adds the obj cgroup pointer to the bo and tt structs, and sets it between them. > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index cf4ab2b5521a0..8e38c6c5c82ef 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -315,6 +316,7 @@ static void ttm_bo_release(struct kref *kref) > dma_resv_unlock(bo->base.resv); > } > > + obj_cgroup_put(bo->objcg); [Severity: High] Does this introduce a double-put and refcount underflow for the objcg during buffer migrations? Looking at ttm_buffer_object_transfer() in drivers/gpu/drm/ttm/ttm_bo_util.c, it performs a shallow copy to create a ghost object: drivers/gpu/drm/ttm/ttm_bo_util.c:ttm_buffer_object_transfer() { ... fbo = kmalloc(sizeof(*fbo), GFP_KERNEL); ... fbo->base = *bo; ... } Because fbo->base = *bo directly copies the bo->objcg pointer without acquiring an additional reference via obj_cgroup_get(), both the original buffer object and the new ghost object will hold the exact same objcg pointer. When these objects are eventually destroyed, both will execute ttm_bo_release() and call obj_cgroup_put(bo->objcg) on the same cgroup, resulting in an unbalanced put and a potential use-after-free. > atomic_dec(&ttm_glob.bo_count); > bo->destroy(bo); > } [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
