Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Dismissed
(max. allowed matches exceeded)
created 3 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/nouveau: fix reversed error cleanup order in ucopy functions

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.

Affected products

Linux
  • <2473ac314387a5def7244eb6d6a345934ed140bf
  • <6.6
  • ==6.6
  • =<6.6.*
  • =<*
  • <ebbaf64d2635d1e78196c067fa8fa582a7dc17f7
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <ab99ead646b1b833ecd57fe577a2816f2e848167
  • <e15c25c7972d38a9f6bf8c3f7f29179a67263eba
  • <4e109faa9ea2b6c04cc5a99e76db3126575a59d1