From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F0C658E2DD for ; Fri, 11 Sep 2026 20:06:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789157175; cv=none; b=b8JIJItDEs2t0vG8CrxAnriRmatfVcmbnEBvZvGJBwWkWsTjGc9iwdpkJjL/28UusiUxLzli0tYsFUQruVcPib/YlaGyU8xQq6voPS06Pgnb86wDKkTYDfd0GtwdN2a5wccs4UgZnJjBgsS0ZLgox7Mei22iyi4q9dwq1BXP1GQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789157175; c=relaxed/simple; bh=5eezWcRbxV9QUwM/a+CUYC21Og2kxIIiw4U08vqEtYc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=P41tGUEE+Pxl1dZ6HMAjpU3sqCJMXwOAgEjYcw/XZj267onAROs9txL51zvm8JYylGiwBdNsy89u/trQdYc88L/s4JXpDLzinxUiGbBVcG8HWryRdbW2Py+1KUsOCG+0sp0IOH/aEH+d2VBRdLmSkv0jya8+824xtuXiATKM1sU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=WJ6SIE85; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="WJ6SIE85" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5762E1F00898; Fri, 11 Sep 2026 20:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789157172; bh=hh2Cts3V5P6zPTjw3bhCZXK0mjWRB4ETcjW4MzE5iTw=; h=From:To:Cc:Subject:Date:Reply-To; b=WJ6SIE85Wipyc6vuOkcQ5M7N3xoMxas+xPTonUMrpHD/wH9HLVl5xq41Q/GpyPu9z Slcqbv+OtdC4sUhO7DBorlmJNZiUncJf7OqLMtkW2p3jY8LK1tORhYflB7CDioehw3 qetO+z274CznkMwNWZBr6OdSaa3eHUFS0bFvnOQw= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-89760: mm, swap: don't free a hibernation slot that is in the swap cache Date: Fri, 11 Sep 2026 21:47:29 +0200 Message-ID: <2026091109-CVE-2026-89760-d3d0@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3359; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=aKHUKTs7/hG7BbWOhCfopXTVaCq7ab2R6Gpr4IAfQgc=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlLIidyL722RNmi0nrRp71KYSFTSr//2fJLqTNlx7x7g jLv/0gc7YhlYRBkYpAVU2T5so3n6P6KQ4pehranYeawMoEMYeDiFICJWJxmWNA/+xDv56Q6Bp8t DBo6rEEheyacOs0wV5QlLOp3i7fQvCk+W47ZNUxYsX9mJgA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: mm, swap: don't free a hibernation slot that is in the swap cache A slot with a folio in the swap cache is freed when the folio leaves the cache, not when its count drops. swap_put_entries_cluster() follows that rule. swap_free_hibernation_slot() does not, it calls __swap_cluster_free_entries() whether or not a folio sits on the slot. Cluster readahead can put one there. It walks a raw page_cluster sized window of offsets around the faulting entry, and a hibernation slot passes __swap_cache_add_check() because it is not a folio and its count is not zero. Freeing the slot then clears the entry under that folio. The folio is now unreachable from the swap table, and the offset goes back to the allocator. The folio is still on the LRU though, so reclaim can pick it up later. It then takes the old offset out of folio->swap and overwrites the table entry there, which by then may belong to someone else. This bug can trigger silent memory corruption, process crashes, or data instability across completely unrelated userspace applications - typically occurring when uswsusp is preparing the hibernation image. I found this while working on giving hibernation slots their own marker in the swap table, which I had discussed with Kairui. (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as I know there are no reports, so there is no Reported-by/Closes to add. Check for a cached folio before freeing. The slot is then left in the ordinary state where only the swap cache holds it, and it is freed when the folio leaves the cache, either through the reclaim below or through normal reclaim later. The Linux kernel CVE team has assigned CVE-2026-89760 to this issue. Affected and fixed versions =========================== Issue introduced in 7.1 with commit 0d6af9bcf383bcdf601e670bb605861b01e318e7 and fixed in 7.2.4 with commit a6df73156f2d85746c69adbf13d0f5ea200e0626 Issue introduced in 7.1 with commit 0d6af9bcf383bcdf601e670bb605861b01e318e7 and fixed in 7.3-rc1 with commit 10d9012e83efedde8718ceaa5053f836e0c8596c 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-89760 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: mm/swapfile.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/a6df73156f2d85746c69adbf13d0f5ea200e0626 https://git.kernel.org/stable/c/10d9012e83efedde8718ceaa5053f836e0c8596c