From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9B64014D421 for ; Thu, 29 Feb 2024 15:53:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709222006; cv=none; b=QDcy/cV5WafPnYFWIPgNAAZmaRJ45jQtjRY7CaR0M8wPvHpLohxbf6yKt2YquRC2qxnRnTiH/dgNL4QUKwTDxfG2EGWHZKUE+Gk86aeXHpzBBc33pF6w6m534dh1XX0SRbu68IjBfFyWIxor7N1Ask2jHt5hUAeyyHwa42PqgvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709222006; c=relaxed/simple; bh=Okoow6z5qBJ6zdv1OXOgiwGALltJZOuYtP0VC1ATt4k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=g7l8/ALCxZumTLiJds/qzMn5ea85sP8YOiw6Hv0pQJglAszK4QZsp6thdd9n7BUI8LFvWZuUOjzshPRTebPgnK7HIt3mnL+84hnuhQLBg+XR/RYWz/SajDmDUUnlf094qZRnoXl3xc8zlCA4NEQdwCMZAH3bZ/5Yb8kjdoXZwXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=miqnsRbg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="miqnsRbg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB5D9C433F1; Thu, 29 Feb 2024 15:53:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709222006; bh=Okoow6z5qBJ6zdv1OXOgiwGALltJZOuYtP0VC1ATt4k=; h=From:To:Cc:Subject:Date:Reply-to:From; b=miqnsRbgvbMNw7XDdEuf60n99oU1jLMMvoMGDmMXN5OADz80UUdtNAok0V/wzdKjP Baq+X7u5NvRDmGkQQl8bBGdYUm2ptE60QH6JaETMduXhQ+u2YfbXQIVb2ZCy5BEvvK 8rn9IOF5iPuWUI99itZj5i8vBlyaKaLePfabGafid+miVekEDCJ4cBi1W5lX9OfWxh DkJYAoLK8DZ8Q5onb1g4cnDIhZYwejoFGQVCzJfLymzereguLURuY4zfmDa1B6SkK9 XwU1odZzzJWEdJtbHJLnv7R5clpGOiIJmASMrRqEP+j1i+yJI9teSd7TiBAKLyBrEm Nb2P93xcTTrGg== From: Lee Jones To: linux-cve-announce@vger.kernel.org Cc: Lee Jones Subject: CVE-2023-52497: erofs: fix lz4 inplace decompression Date: Thu, 29 Feb 2024 15:52:57 +0000 Message-ID: <20240229155245.1571576-38-lee@kernel.org> X-Mailer: git-send-email 2.44.0.rc1.240.g4c46232300-goog Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-to: , X-Developer-Signature: v=1; a=openpgp-sha256; l=3203; i=lee@kernel.org; h=from:subject; bh=Okoow6z5qBJ6zdv1OXOgiwGALltJZOuYtP0VC1ATt4k=; b=owEBbQKS/ZANAwAKAVGvii+H/HdhAcsmYgBl4KhPK4xXuGJMG99HjzkV3H8VWf/JrC5RDjf9J sZFiYHT/ImJAjMEAAEKAB0WIQR2tsk1o74gmpTwh0hRr4ovh/x3YQUCZeCoTwAKCRBRr4ovh/x3 YWnjEACsukL1TL5guZhz2EfDguSXKqxAcdgpBGWV3VzFFcPO/UHlvJ9JgpbVxbifkQ+LtklT3cS XwK2aArOKZHESE5GvgjKQSTFP7D3sfwTM/LOOR2mK1bmO2EfLIA5ckS6eYTggKScgoAEYdE9mqL WTMQgHHfsaC4CxtQOc8ndEqYQ7Ss4M9fqQpVvODNy14/Ryh6Dn9li8ULC/1zdT3o03iX/t6gzu1 hXeVVS94Rax2/v+7waM8FIUi/dJU7zv84KYfKzJGyT4gw/Z1nwbV/8puERuQ5wsBP1yjy59gBcZ glBqhelZ19FSFKkgRkxl6XTp8TzFFX21+2IotupGb9mnxFCVExcbvcenVdT0Gv6AoPjjLGRBu62 omeNGMEZ9qcTFBEcXCKLJX9eUsbBqum+yL5Bh7EOz6zU9vH95wz7GR1a8KatzjZestFPM5yyxW2 o1o1lVkVO08GHHvX+ynhOEF9xCsDhGfoGukmvvZ816QAoUDFOL1+59jK+yneBfA/W8PlsByt9K/ 3c3mchVNZ2R1Q9XXj37Qm47l7+lr8TF0eVhki6BXVj5Cko6CApdkPgg+CZwxvulHUStGN5i5rw2 Pxcj9li48crMjNOMVk9i0ccj/9F5+mmDYUPJU0gIN2kfTGqb36dH3LJgu5uy1FJi9Vww4HXPV1/ 5LvSyiA8J46ebJg== X-Developer-Key: i=lee@kernel.org; a=openpgp; fpr=76B6C935A3BE209A94F0874851AF8A2F87FC7761 Content-Transfer-Encoding: 8bit Description =========== In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. The Linux kernel CVE team has assigned CVE-2023-52497 to this issue. Affected and fixed versions =========================== Issue introduced in 5.3 with commit 598162d05080 and fixed in 6.1.76 with commit 33bf23c9940d Issue introduced in 5.3 with commit 598162d05080 and fixed in 6.6.15 with commit f36d200a80a3 Issue introduced in 5.3 with commit 598162d05080 and fixed in 6.7.3 with commit bffc4cc334c5 Issue introduced in 5.3 with commit 598162d05080 and fixed in 6.8-rc1 with commit 3c12466b6b7b Please see https://www.kernel.org or 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-2023-52497 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: fs/erofs/decompressor.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/33bf23c9940dbd3a22aad7f0cda4c84ed5701847 https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de