From nobody Tue Dec 2 01:30:04 2025 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0DB62D8DDA for ; Fri, 21 Nov 2025 13:13:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763730796; cv=none; b=Ch2Uay48L2hBsh09YWS1CYyL4aHYMpVwii2kf06wLFwy4bY1SgDRqDl+6FCbJPP+JFIbQ2cyy8t1ehEW1HFNTM7QHdjGi9pBJR0fqtlQH6On/fWJ9UM9ywZKFy2KAi8MNajTBVs/nBBZE/REu4GNcwlABl/Lv/C55Y+6FIg+jm0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763730796; c=relaxed/simple; bh=rE/SarrQIWideNXRyOgnbkN6JjxjL9SMadfP3/CRCOo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Qr22p6WH89LWsjXLvI2l5xHuQkPzoU0UnKiaPQSE6xaQdsj07WdFzHizgG74PbR2TMk6QZdBk6c01hLYpnxnREgKvjaAB+vbS+COUuwsqVFSr1PXpwW7TixNrvQQBigZFVuaGcIYf6wSrq1CdccnLN8izz/5BHSnJ0v7Dxkhm5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=auw7qQLz; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="auw7qQLz" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-7b9a98b751eso1611443b3a.1 for ; Fri, 21 Nov 2025 05:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763730794; x=1764335594; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=TcwG/NJzFAcxhEUfrYRg693RnY+JUPTamI6o974/FU4=; b=auw7qQLzjWwPMfuJ38W5UHPaGINKPeK97bZWMEqWNlgVwNI40PLcotitUgfFmq3tUG QaOoG0eaneX7jLXJlzuLA1Bo4oWg60fotIsDIASB07X6hOBjHwVuyALM5XVTEwK6F0tY a9hNaXaeoFksnsxWDzGP7luEbOPvI+bcdF4aQR3PtNjAyosT83yX3h7G4hVG6qtT/zko poHCQunNPyUZUggaXQcR44xePuFwwJEpAdBuG7Vw7eDbAfy5EfRpAaQUlmibUgStdcWM c2SQLy17jVUus5Bx+iG+LJgVUo5VKWobmwsFo2LFDXG2tekn4P1Abj4UYQHKf7SXtOhB QkFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763730794; x=1764335594; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TcwG/NJzFAcxhEUfrYRg693RnY+JUPTamI6o974/FU4=; b=XX5JpXKVf/7orNnLmACtA2nxDw+IGes4m2A+pzQQSFbveb5UfRjSuZWr3djPkowOvn r0ahT8Mj6eT8GnlwsrPo1EoRxpXMXlLh0mnj77j0svgf/R/cGougF+DF+UmTWZ25T4Ry CRNsj0CK86C/MuirNokj1/EIN69tDu3GfAUJMkaRCKASNFVzPO38/OZh2zerALIh3AYZ 7WQ+lMbJUSPK7KwxfXr3nzbW7iIeLAIgeox6OPMIZPomrIwnq3lR2nSE0LLTFv+DUCZr K0M8ee+ARVup4o4Nty8LZfoHQU+nwb4FPQqUiw5inYNQfTqUVZJUHxXdhtvXLk/C8gwN fo1Q== X-Forwarded-Encrypted: i=1; AJvYcCXSlwQUYxYd9/bCaBWvbMmyE6N8g3LCebYaPTxkqbdxUa/pXh4daybGT1ykgvQUxeOiEPkqwoUHsmNp0Cs=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3vmFZjDaCWoHUoUy6gvneywBA7gGdIJyipfWUUIX1KGDrXCTr ivkF5MNNvPb+K7ukizwBoIsXU30kq2RvO6PPsC/5zUNmDxbXqymAihU3 X-Gm-Gg: ASbGnct1/3e/ylAKlZainY6oR6bHnabZgJgQ73ZapuHEZMWtQKq8klpjzQle3QVNOxv P+OFZ34edBzgfzHehHq4Pzbhx+P2Gi/R8QOxj+dwlEsCct83kjTmJJPR/BvxAZTrDDsMNQj/hGF kna0xWMX0HJPDob785nK4DQizRVxSC9WWeY6Dcv1O6JJQDBXou4tnaXe0YWEXpS+Xr47Eq5OQJh 39t09H40O1tqw3xiiQO+iqcNa/yloEnsIwb+D3CPHOcyQoOFWPTZI58X14EL7GLwCeuj7TJy7V5 RkwsAHJ4I3M55woisxJXCa1lZNmc8NbZj53jerT7Mn4rpEB/g6oX3jIHs4mQo1YQdD7eYFvGEPG a/rDonoA5Y/qVJZJebThbyCwYgrT14yed+o2TogO2grkw768mkH0HRiLGr0m5ZCJL87+FDQeoJE jqaXF+JtTYs6NnuARnIce7lUbHmMMikQnYj/c= X-Google-Smtp-Source: AGHT+IHVq8m64LagXR7W/MUGL/n3aZK2syb3kGs3Kx9En4d48IXWK5IXTgV1/krruozFO/ncHQl7hw== X-Received: by 2002:a05:6a21:e081:b0:35d:1bcd:6887 with SMTP id adf61e73a8af0-3614ebc1b71mr2998609637.16.1763730794094; Fri, 21 Nov 2025 05:13:14 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:4240:d7dd:15df:5810]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7c3ed37b0c7sm6069280b3a.20.2025.11.21.05.13.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 05:13:12 -0800 (PST) From: Deepanshu Kartikey To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com Subject: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite() Date: Fri, 21 Nov 2025 18:43:05 +0530 Message-ID: <20251121131305.332698-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When a write fault occurs on a memory-mapped ext4 file, ext4_page_mkwrite() is called to prepare the folio for writing. However, if the folio could not be read successfully due to filesystem corruption or I/O errors, it will not be marked uptodate. Attempting to write to a non-uptodate folio is problematic because: 1. We don't have valid data from the backing store to preserve 2. A subsequent writeback could write uninitialized data to disk 3. It triggers a warning in __folio_mark_dirty(): WARN_ON_ONCE(warn && !folio_test_uptodate(folio)) This issue can be reproduced by: 1. Creating a corrupted ext4 filesystem with invalid extent entries 2. Memory-mapping a file on that filesystem 3. Attempting to write to the mapped region The sequence of events is: - User accesses mmap region -> page fault - ext4_filemap_fault() -> ext4_map_blocks() detects corruption - Returns error, folio allocated but NOT marked uptodate - User writes to same region -> ext4_page_mkwrite() called - Without check: folio marked dirty -> WARNING - With check: return VM_FAULT_SIGBUS immediately Fix this by checking folio_test_uptodate() early in ext4_page_mkwrite(), before any code paths (delalloc, journal data, or normal). This ensures all paths are protected. If the folio is not uptodate, unlock it and return VM_FAULT_SIGBUS to signal the error to userspace. Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Db0a0670332b6b3230a0a Signed-off-by: Deepanshu Kartikey --- fs/ext4/inode.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index e99306a8f47c..18a029362c1f 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -6688,6 +6688,14 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) if (err) goto out_ret; =20 + folio_lock(folio); + if (!folio_test_uptodate(folio)) { + folio_unlock(folio); + ret =3D VM_FAULT_SIGBUS; + goto out; + } + folio_unlock(folio); + /* * On data journalling we skip straight to the transaction handle: * there's no delalloc; page truncated will be checked later; the --=20 2.43.0