From nobody Tue Dec 2 01:05:43 2025 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (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 2352713AD05 for ; Sat, 22 Nov 2025 01:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763776673; cv=none; b=ocRTKcYRkrvOzZ9jgnP9Qb5ZbVw4r1HT7AuG2niUq/06LcwJbGPYz6FaaRFGcd9I1Sfo+D3DEBtmcjThjBb+DIB//9IczPAfCgCX5WYh0jILJSBvztkfwYcwGO0CObFz+EuRucVaPCX4Vqzq+vgOfjLPWjgraj8Dl6ejKMmNKIw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763776673; c=relaxed/simple; bh=or5fkGeUuho+9cgKiVA6L69Itywqwi1cgjg/8vpEWDE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IWXYFmP5TOdslcPZJCJWQwgNIgLlxBO/ayFBkV6f2vq2BgkKymX/X2yRBloRRzeALyXyyoXi1kQ3AkhV0t2jl/llmp865QgMUe3qvDi9xN2vw81I5VRpAs6ZSr4SMfKZMg5yfcMgdXyDkbfq4tq0Q4wt5ncK5jZl19/f3OV9MwQ= 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=YYKjGeja; arc=none smtp.client-ip=209.85.216.52 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="YYKjGeja" Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-3438d4ae152so3009855a91.1 for ; Fri, 21 Nov 2025 17:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763776671; x=1764381471; 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=yRFiigzAnXPWCUAfF7TMX13w9dqE7WROsRKqo4+OjQg=; b=YYKjGeja8tpPgGlJ+jz+9HLZUAWkiwikckFi7Y1xNGtWYKGNA4tYuN08Hp2MBYzkSe bzRkfSITIPa9olZHv5eM7ZC+wEVbTgzcHKXUy92U+ccnDQ9w2oCUnjjG66CbzeLxUc8k yuzRCJ05+2wXn7DotKILSRKviBXcj9WFO0BcpvyCkpZysBowwtuaY6polkmozRGfmuLq 6LkbGBskOC0/Q3BP8vAWmDEMvEPgquCXUEIx0pr282iKe7WsX6+OCLrUAOefrhCYIXau N4+3oeEIVZnCpVdGR6ElEVjC12m8PFtlY4Vp5cVghOu19U7YBGaeP0Z1zeX9ViM0NOl8 YWDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763776671; x=1764381471; 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=yRFiigzAnXPWCUAfF7TMX13w9dqE7WROsRKqo4+OjQg=; b=d6mDiEg3WhLvelshZVe55HxhwsOAAeFuka+cTa3VnhpY+SEhWPQhSZ32PfwfU0Ctgq C0w0pRJgAonHsIAXkN6awnx6G9k52oR54iLTLAQON/gFXiTXEUPgLYRv/32HVAWL+Rqs iymfj+ljOXMVJwIJxVCpvt13jeMt9XSIbSCMZ7h8PIz4m7isAbiPs6kvT8VWTugDI7EU SbVzODeyYuv95RoGOPaWVFu+/KoVOoq+Y+60B8qMRtjdMlDX9Qsf1UKRZWCnPODo0LXc Ju4SLMOMySxcgIaLMktKJddKQrykqbgKvQpW8RqEO1gIhLqVqmP7tUSddb8flgJsltXz vZeA== X-Forwarded-Encrypted: i=1; AJvYcCXGP1D9kCa17zzccUB1SSagJ4sZEGkg/XxfsUoBabM4wDey052l895VivrksXCuygtFhPPKUpEs5vsca6A=@vger.kernel.org X-Gm-Message-State: AOJu0YylKExuS1lf7+x41UbO3CqNhLlbknxNWzU+PoYfbFWsW1h26oJJ JvhGUYslwdZ31C8eByqjAD9ux9zqxOwcCHAvc77MBOWVnAkcHiL79/cHdpAEgQ== X-Gm-Gg: ASbGncs4LodlfXpjbju8WhzP3x9YRWMeNA7HgBPxLeQ2gGNmK3HmX84jibtyz5334QJ Cby9rQT71byzA1a7/F6r03MUWheaajX+bhRkxnZSJMi21XKcCuVYONXQywZ5igYjALZ1fdZb/Li oje6xQVhO0XeOz6zdueCoMloZPgqSQoVnTQevcJ7bJ3/an0ZSLMqbWb5w0J495+ulMCiifKEgK6 LNHO6RW4sAEGYCuSQMFxK+dApEPR3A0iDBzfD7UUsgFHLQfxNnSV1EzOE9kgZhnajL9oqUli1UJ y7ww6qIwqLpROYJoFVc5dzFo5+c3PAQ+C3jWptjM67kNaXvTh+f7p/EPRKEdasNuxoTUxdT7JlE EBpU/brx8+KWsAoPP+jRQP3WwDrwdPsaiiiXlkW/wqR0C8Inlux5wfUWUk9fVYAXy5UKzGNpH66 6X+YtpKW16xVP0eUoDvDIGrQstn3kMlVzi8/euNecVRLc= X-Google-Smtp-Source: AGHT+IFDvnDexWq3NMClg3rlwVRmX4OYTyPq0boMqZIijVApm3aAPsHh8DJ4Fr2wGFGp//jq9F/FKg== X-Received: by 2002:a17:90b:4f42:b0:32d:d5f1:fe7f with SMTP id 98e67ed59e1d1-34733e937bdmr5124446a91.15.1763776671299; Fri, 21 Nov 2025 17:57:51 -0800 (PST) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:389d:bc95:32fa:5cbc:5c]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-345b04d7305sm5271192a91.11.2025.11.21.17.57.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 17:57:50 -0800 (PST) From: Deepanshu Kartikey To: tytso@mit.edu, adilger.kernel@dilger.ca, djwong@kernel.org Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com Subject: [PATCH v2] ext4: check folio uptodate state in ext4_page_mkwrite() Date: Sat, 22 Nov 2025 07:27:42 +0530 Message-ID: <20251122015742.362444-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 delayed block allocation fails due to filesystem corruption, ext4's writeback error handling invalidates affected folios by calling mpage_release_unused_pages() with invalidate=3Dtrue, which explicitly clears the uptodate flag: static void mpage_release_unused_pages(..., bool invalidate) { ... if (invalidate) { block_invalidate_folio(folio, 0, folio_size(folio)); folio_clear_uptodate(folio); } } If ext4_page_mkwrite() is subsequently called on such a non-uptodate folio, it can proceed to mark the folio dirty without checking its state. This triggers a warning in __folio_mark_dirty(): WARNING: CPU: 0 PID: 5 at mm/page-writeback.c:2960 __folio_mark_dirty+0x578/0x880 Call Trace: fault_dirty_shared_page+0x16e/0x2d0 do_wp_page+0x38b/0xd20 handle_pte_fault+0x1da/0x450 __handle_mm_fault+0x652/0x13b0 handle_mm_fault+0x22a/0x6f0 do_user_addr_fault+0x200/0x8a0 exc_page_fault+0x81/0x1b0 This scenario occurs when: 1. A write with delayed allocation marks a folio dirty (uptodate=3D1) 2. Writeback attempts block allocation but detects filesystem corruption 3. Error handling calls mpage_release_unused_pages(invalidate=3Dtrue), which clears the uptodate flag via folio_clear_uptodate() 4. A subsequent ftruncate() triggers ext4_truncate() 5. ext4_block_truncate_page() attempts to zero the page tail 6. This triggers a write fault on the mmap'd page 7. ext4_page_mkwrite() is called with the non-uptodate folio 8. Without checking uptodate, it proceeds to mark the folio dirty 9. __folio_mark_dirty() triggers: WARN_ON_ONCE(!folio_test_uptodate()) Fix this by checking folio_test_uptodate() early in ext4_page_mkwrite() and returning VM_FAULT_SIGBUS if the folio is not uptodate. This prevents attempting to write to invalidated folios and properly signals the error to userspace. The check is placed early, before the delalloc/journal/normal code paths, as none of these paths should proceed with a non-uptodate folio. Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com Tested-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