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, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure

In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.

Affected products

Linux
  • =<6.6.*
  • =<*
  • =<7.1.*
  • <fe3b45b56b6c3d4b6b341de27fa291005287a21c
  • <5.15
  • =<5.10.*
  • <46d59ff421824b6483549d87f14efffbbbd1f6cb
  • ==5.15
  • =<6.18.*
  • =<6.1.*
  • =<6.12.*
  • =<5.15.*
  • <70a38f87bed7f0694fd07988b47b2db1e10d8df3
  • <cb3420c047957e565101585bb4f15e1a6e3de6b0
  • <5.10.261
  • <3a5c55a19cad62f2973be25fe96a1a9e7f618e8a
  • <84008bf1860e0ef8059a7583a1163f36b704d08a
  • <7ce4c23e783e766507b2cef27bbf97e9ca944f1a
  • <6cd84cefd8b73e85b9eda17b319bd40a670f3a38