linux-kernel - Re: [PATCH] zswap: do not crash the kernel on decompression failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z76Go1VGw272joly@google.com>
Date: Wed, 26 Feb 2025 03:12:35 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Nhat Pham <nphamcs@...il.com>
Cc: akpm@...ux-foundation.org, hannes@...xchg.org, chengming.zhou@...ux.dev,
	linux-mm@...ck.org, kernel-team@...a.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] zswap: do not crash the kernel on decompression failure

On Tue, Feb 25, 2025 at 01:32:00PM -0800, Nhat Pham wrote:
> Currently, we crash the kernel when a decompression failure occurs in
> zswap (either because of memory corruption, or a bug in the compression
> algorithm). This is overkill. We should only SIGBUS the unfortunate
> process asking for the zswap entry on zswap load, and skip the corrupted
> entry in zswap writeback.

Some relevant observations/questions, but not really actionable for this
patch, perhaps some future work, or more likely some incoherent
illogical thoughts :

(1) It seems like not making the folio uptodate will cause shmem faults
to mark the swap entry as hwpoisoned, but I don't see similar handling
for do_swap_page(). So it seems like even if we SIGBUS the process,
other processes mapping the same page could follow in the same
footsteps.

(2) A hwpoisoned swap entry results in VM_FAULT_SIGBUS in some cases
(e.g. shmem_fault() -> shmem_get_folio_gfp() -> shmem_swapin_folio()),
even though we have VM_FAULT_HWPOISON. This patch falls under this
bucket, but unfortunately we cannot tell for sure if it's a hwpoision or
a decompression bug.

(3) If we run into a decompression failure, should we free the
underlying memory from zsmalloc? I don't know. On one hand if we free it
zsmalloc may start using it for more compressed objects. OTOH, I don't
think proper hwpoison handling will kick in until the page is freed.
Maybe we should tell zsmalloc to drop this page entirely and mark
objects within it as invalid? Probably not worth the hassle but
something to think about.