From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-89548: SUNRPC: always drain cache_cleaner before destroying a cache_detail
Date: Fri, 11 Sep 2026 21:43:57 +0200 [thread overview]
Message-ID: <2026091120-CVE-2026-89548-d39f@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: always drain cache_cleaner before destroying a cache_detail
sunrpc_destroy_cache_detail() only cancels the global cache_cleaner
delayed_work when cache_list is empty. During per-netns teardown
cache_list is never empty because init_net's caches remain registered,
so the cancel never fires. After unlink, the caller proceeds to
cache_destroy_net() which kfrees the cache_detail while cache_clean()
may still hold a dangling pointer to it. The result is a
use-after-free: cache_dequeue() takes cd->queue_lock on freed memory,
and cache_put() dereferences cd->cache_put as a function pointer from
freed slab.
Drop the list_empty guard so that cancel_delayed_work_sync() always
runs, ensuring any in-flight cache_clean() completes before the
cache_detail is freed. Re-arm the cleaner afterwards if other caches
are still registered.
The Linux kernel CVE team has assigned CVE-2026-89548 to this issue.
Affected and fixed versions
===========================
Issue introduced in 3.4 with commit 820f9442e711a81749e70c40f149fc54c4ce0ca8 and fixed in 6.12.109 with commit 9d44836f60c8c29bcdb1471fd9202387c642a890
Issue introduced in 3.4 with commit 820f9442e711a81749e70c40f149fc54c4ce0ca8 and fixed in 6.18.50 with commit 2e861ce2aaa468351a6a47c4cbb4971ebb740c7b
Issue introduced in 3.4 with commit 820f9442e711a81749e70c40f149fc54c4ce0ca8 and fixed in 7.2.4 with commit 3d60fdf951143d6ef4e352e2f8eb852286701726
Issue introduced in 3.4 with commit 820f9442e711a81749e70c40f149fc54c4ce0ca8 and fixed in 7.3-rc1 with commit f42d0fda0c67695db6bc704b04b7c10240805377
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-89548
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/sunrpc/cache.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/9d44836f60c8c29bcdb1471fd9202387c642a890
https://git.kernel.org/stable/c/2e861ce2aaa468351a6a47c4cbb4971ebb740c7b
https://git.kernel.org/stable/c/3d60fdf951143d6ef4e352e2f8eb852286701726
https://git.kernel.org/stable/c/f42d0fda0c67695db6bc704b04b7c10240805377
reply other threads:[~2026-09-11 19:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026091120-CVE-2026-89548-d39f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.