From nobody Thu Sep 24 21:47:55 2026 Received: from mail-pz2-f34.google.com (mail-pz2-f34.google.com [74.125.228.34]) (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 DB5843612FE for ; Sat, 19 Sep 2026 18:10:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841403; cv=none; b=cvXcj9SO8gJ4R5FYUYf8RM6Yjrtao49Ob1rsLU7IhUvzA9rJdijnw2mwqDNKTdcYBBDaGDipa7ZDqgXltR5/xLBZfXhcNeZfrs+pm/UFH3Q1pLzYX1f52eQv5FcWKoWC79lMTVck1LuouUUoxbJEKnu7Iqw9HRQfQ96rTpWnFzc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841403; c=relaxed/simple; bh=aAVSFY76lgQO01OrSs7ssic/mi+/CMLDEcviR6+3myo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HWQ3Vo58C6twok1ruYaH1MP7GjvUC+Fh3GhbsCdqsXCbrOmvyI7xbLucH9QWK7rJWu/e4AQZ01JsT5lKPrNmyqG/I/ATH8STy9mGpNG+kVJe1sTv4ctE6Z2DUvw9CTAHTcsH+d7sLWy9WVyMcv9EYwSYpXoPvYzMnD615IAYznY= 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=raE5cUlQ; arc=none smtp.client-ip=74.125.228.34 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="raE5cUlQ" Received: by mail-pz2-f34.google.com with SMTP id d2e1a72fcca58-8748f34b1f2so1735087b3a.0 for ; Sat, 19 Sep 2026 11:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789841401; x=1790446201; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lGaU0pxyX4HFuiN75gQbxqPfhwQhSeDU8rlnsi/9iUE=; b=raE5cUlQwsuD61WNt03zs4CAbcF/CCnSxuCtzmfkp5LqT9WPC4Avw0iWxdctigd8rt VZWbutg//Vc9Qga2KZxUAuE25zPfHf6WPdAiABHr+nFDqohieY/LNDEeaJo0xXNFydt7 fNzBSsDd+kEeCp2jNnWuqYgTYlUvtZpIOrJ2sCHmw4JabzU7MuMcSX0l8PaOkw9zTucH Sered+IS549czDWPXr6Q4jRfGXslDDkYs/icNxlppjlsvpaCpI21HzADlOT953WFXs8o +l/Mj4cWWJt/hdrcVnvKcL59N4Gntg8dc8c/B7uJGxAwQITSLAVhki9fahpVPdDwQCiD KMwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789841401; x=1790446201; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=lGaU0pxyX4HFuiN75gQbxqPfhwQhSeDU8rlnsi/9iUE=; b=p8JB6LI254ZRgAlWkK31eU3AtY+vQBYFgCXzllPDt7xD1u7deibIf4XkCGXPtsM/n+ dRumvz/PcblsJrm7iFCO49T1s+GG+gMZtpmGuHH1VsjRYfGZdBKq7er11m2c8Wd05P/2 y/Ll7DbNDwjNSWSy0aANIJJgkp442Fgq3SAo/YvA30LfHTSH6l1ODVjRMcdk0e4Wi+DJ 7hannxIU3ucX0daHXvRLiJluSCHEyyM17sWstIJsUTyJ1kBR0tY6BVjlE4+5HbVnEWpx h5s9y63ezMI/SyI9LPWLJhv6gsaIIv3kxnwMFsl3kapv4Ydzw9+tyl9t8d8wpjFeDXG2 pPuw== X-Forwarded-Encrypted: i=1; AKwUvBxV1rfnTLHnTUzLmDAfjbZsXCL2IH0qIFZjV89WSy050Zj4gNuJ/4PnYBuhc90xgwfqGmNqPab+pL8MZqE=@vger.kernel.org X-Gm-Message-State: AFuF++mKVS+SPN8XRILkAk03kFV7Y6NEwCm+za66w5tefQWd7hiuq6SR GCdkKwcZzksga5hP4vwO9SmwCMYrjer+QCoFSO4NtEGd0PkfwuEnMzfp X-Gm-Gg: AYBFou1q7RcVpdNdDls5RMSHZ7pgt811LxmGaZO+tzcjbWpiFkbLj79ZxCU98/rhxAi iBmrpiio2UmicAEoMPY0HcCQz62m79GQeMPwdkOnk6P3UuewZ7/6QiMaQ8esJ5s/a1ifAgjTaSl VXsvSgBBoA/SlfKDo1rNohzFHxqtutYiKS3NoxKnXJN3mg/XXCE4hBdE3t34At/4xUt+zwNqBuN QW3s/B0+yeoyrCkF320RU01SmSjnzFvqk0t6zhpvPhR4mgXhSsNaX3bYn6a1UErORyhEjYTzKtU AyYB6UjRec26n/F8x7/a1kUNMOCu3lV9soZTOrxLn0xQYBWNGO1kHEu+hmwd4IVT2K5ElchN6WE XADHKypmjamhCKAonUzwJ453ez8NqG7zypnrPhnLQDd1soSIz3F/v5f5zZnVBkny/QJnSxuASNH 0EmwbE1yPOYQa0Q7wiFRFEsvnZnHcDoVcBkkvecgp2d/pWz1bb373DKDRqjtohOxWhgLPOCwwhQ Fr8jFyRCHs0eykbOG9GcP+iPyzlmsoynheueq4ao5R9gkNiVR+shUrxQD8QU9wAAFYOTyH6lebq jB7WBrVyxQ== X-Received: by 2002:a05:6a00:1d8c:b0:874:705d:f657 with SMTP id d2e1a72fcca58-874deced87fmr8895022b3a.37.1789841401037; Sat, 19 Sep 2026 11:10:01 -0700 (PDT) Received: from phui-2.c.googlers.com.com (67.51.127.34.bc.googleusercontent.com. [34.127.51.67]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-877a94f8c39sm1190168b3a.28.2026.09.19.11.10.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2026 11:10:00 -0700 (PDT) From: Hui Peng To: David Sterba Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] affs: reject out-of-range blocks in affs_free_block() Date: Sat, 19 Sep 2026 18:09:55 +0000 Message-ID: <20260919180958.1362943-2-benquike@gmail.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog In-Reply-To: <20260919180958.1362943-1-benquike@gmail.com> References: <20260919180958.1362943-1-benquike@gmail.com> 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" affs_free_block() accepts any block number below or equal to s_partition_size, then subtracts s_reserved from it: if (block > sbi->s_partition_size) goto err_range; blk =3D block - sbi->s_reserved; bmap =3D blk / sbi->s_bmap_bits; bit =3D blk % sbi->s_bmap_bits; bm =3D &sbi->s_bitmap[bmap]; Both bounds are wrong. block is a u32 taken straight from the on-disk file header or extension block, and nothing rejects a value below s_reserved. For block =3D 1 with s_reserved =3D 2 the subtraction underflows to 0xffffffff, so with a 512 byte block size (s_bmap_bits =3D 512 * 8 - 32 =3D 4064) the index becomes 0xffffffff / 4064 =3D 1056832. sizeof(struct affs_bm_info) is 8, so &sbi->s_bitmap[bmap] lands roughly 8.45 MB past an allocation that is only a handful of entries long. The upper bound is also off by one: s_partition_size is a block count, so the last valid block is s_partition_size - 1, and a block equal to s_partition_size is accepted today. Because s_bmap_count is ceil((s_partition_size - s_reserved) / s_bmap_bits), that block yields bmap =3D=3D s_bmap_count exactly whenever the partition divides evenly into bitmap blocks - a one element overrun of the same array. Mounting a crafted AFFS image whose file header references a block below s_reserved and truncating the file reproduces the underflow variant: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in affs_free_block+0x5d4/0x670 Read of size 4 at addr ffff8881068d4c00 by task init/172 CPU: 2 UID: 0 PID: 172 Comm: init Not tainted 7.3.0-rc3 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl+0x70/0xa0 print_report+0x153/0x4c6 kasan_report+0xf1/0x120 affs_free_block+0x5d4/0x670 affs_truncate+0x635/0x1520 affs_setattr+0x367/0x470 notify_change+0x941/0x1050 do_truncate+0x1ba/0x210 vfs_truncate+0x305/0x490 ksys_truncate+0xd9/0x160 __x64_sys_truncate+0x59/0x80 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D KASAN calls it a use-after-free only because the wild address happened to land inside an unrelated slab object that had already been freed; the allocation and free stacks in the full report belong to a boot time kobject_uevent_env() allocation. It is an out-of-bounds read, not a temporal bug, and where it lands depends on the heap layout. AFFS already has a helper that encodes the valid range, and it has done so since the beginning of git history: static inline bool affs_validblock(struct super_block *sb, int block) { return(block >=3D AFFS_SB(sb)->s_reserved && block < AFFS_SB(sb)->s_partition_size); } affs_bread(), affs_getblk(), affs_getzeroblk() and affs_getemptyblk() all gate on it, so a block that affs_free_block() accepts today is one that AFFS has always refused to read. Use the same helper here rather than open coding a third variant of the test. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM Signed-off-by: Hui Peng --- The last valid block is still freeable: affs_init_bitmap() explicitly marks every bit mapping to a block >=3D s_partition_size as allocated in the final bitmap block, so s_partition_size - 1 is the highest block the allocator can hand out and affs_validblock() accepts it. I have left out two further checks that I had initially written, because both are unreachable once this patch is applied and I did not want to mix speculative hardening into a fix with a reproducer: - a `bmap >=3D sbi->s_bmap_count` test after the division. Given s_reserved <=3D block < s_partition_size we have blk <=3D N-1 where N =3D s_partition_size - s_reserved, and s_bmap_count =3D ceil(N / s_bmap_bits) =3D floor((N-1) / s_bmap_bits) + 1, so bmap is always <=3D s_bmap_count - 1. - an early return when sbi->s_bitmap is NULL or sbi->s_bmap_bits is 0, guarding the division. affs_init_bitmap() only leaves those unset on paths that force SB_RDONLY (including the ro->rw reconfigure path), and a read-only superblock cannot reach affs_truncate(). Happy to add either if you would prefer the belt and braces. Not Cc'd to stable and posted in the open: per Documentation/process/threat-model.rst, "bugs triggered by mounting a corrupted or maliciously crafted file system image" are regular bugs rather than vulnerabilities, because mounting is privileged. Say the word if you would like it tagged for stable anyway. Found with a QEMU/KASAN reproducer built around a crafted 4 KB AFFS image; reproduced in six independent runs. diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c --- a/fs/affs/bitmap.c +++ b/fs/affs/bitmap.c @@ -46,7 +46,7 @@ =20 pr_debug("%s(%u)\n", __func__, block); =20 - if (block > sbi->s_partition_size) + if (!affs_validblock(sb, block)) goto err_range; =20 blk =3D block - sbi->s_reserved; --=20 2.43.0 From nobody Thu Sep 24 21:47:55 2026 Received: from mail-pz2-f12.google.com (mail-pz2-f12.google.com [74.125.228.12]) (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 9C64137F32E for ; Sat, 19 Sep 2026 18:10:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841404; cv=none; b=Ny7O2onRcQ9kp9bW0eWGJ0Trz0Rd4q3FHnlFwbIV9WqYItMUVjr7LJXAo17nLkKPLsOlZ/q7TTuJE/amoZfnj+GemwTsqxXWiBN2AuyMgzLV8lbU2LAPTt7yqMIKZe/ZjuKByKGxnAP1PF32aoLncxe0F24FpXBERTUFSprX/cM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841404; c=relaxed/simple; bh=9fga065swnGZFhkxLqcDw2eL9TSjYMuP6kGkdbXxN1E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hYDWZQX8kfdq+5Q7CxzjYL+E/gblgVQIhkzqZWKSWtzXUh+Fe8WIbHBUnDTkQ2oaOOYWvGIc31cWtG0Ef/Q3cKOnCF3QGI3PnsOpTB5iz8FVFKSAJ2djorh5Q2SQCYl7X7a99H71P1SEjJgmoJ+UFWtpzAoeOSsGSyjgprXIdkM= 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=FVJUp/G2; arc=none smtp.client-ip=74.125.228.12 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="FVJUp/G2" Received: by mail-pz2-f12.google.com with SMTP id d2e1a72fcca58-85469a3490bso1934832b3a.3 for ; Sat, 19 Sep 2026 11:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789841402; x=1790446202; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=QEqihKQUEKRrqjsohNMETPXFyalbXU71edcLsvmgqxw=; b=FVJUp/G2g3dEpsJDInplThwjBYeDIuVHEWkIG5HG6SkvxQRGsZSrG+u6rvU9x51uBp ljp9o+RePArVBYqymg4vpldo8YvCRoE8mykk6N+wt1dspSowD6ONLIIG5IaxlO6tW+++ Uwd543kHq1pWgTx4K9hwRX8mz58B5WhIdTd8ju8TV04/nQLDrC3lYynrXg8C9aQ5QhA4 90opTG8EBZtxAygnqGGPJglYlk0MFWPG774/LHGBUjLik/kMKBcg0afNJQIVZfB0N/S7 /UVcDyW2ql+j1JvpIV+kuck1iUpnTp/1dKM2qqtQx3qfHmrVPwYxGLvH+F2V5FFowTaY sjaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789841402; x=1790446202; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=QEqihKQUEKRrqjsohNMETPXFyalbXU71edcLsvmgqxw=; b=NES58FW+LaF5fjubLXSFFYyMcz/pt7bVK78FmlWYOKFVTtMlif7uSZpkAOJYOJOKKR lBBeNZbUqAolaM+mPmo6W/34RLD44WGEUJDfKlk5vI2LdqCQk70NwWsYOcjXI8vyHQ+Y lx7nLwliGIZLUalw+ml65Ke1O/Sc/0RZEZWgCehlaP4Fp2hiHrFPl4ZTmN424H20O0mU tC4enlNi8a22Cjwe0Ml9lYxDj1r5UNuSMwIUrKO0/hf8Ohwl9SN3D0QnswrCfbaQCrsL Igif/9zNyKxYbwl9d/6qwR85Ulm403Kwu3YpeXUGF0AixL26psreS676amrWpWxZLZpv qx2A== X-Forwarded-Encrypted: i=1; AKwUvBy4k1INKWbW2sWnUsjMgAYWT9bzlCZV+N7wmLSiUqK+P2F//fQwbAKWGOJbnYrLizyUdmApTDBb8w17doI=@vger.kernel.org X-Gm-Message-State: AFuF++nXW0Bx6IBQ3zC6GgaCYLzuXrxuxI5Jus7PqaFn9YthwvwKCIWn /lgcz5Z7j6oWsodxFym5tpZgACZhJPa63x5EOoGjD/8BSTpiYYHWfV6T X-Gm-Gg: AYBFou2RiRXQCAo1CrgbjyDxzT2AmGZ951uvV4bD/nGOEXCbyvyWu8yXH2HbY1fouPK 1EprAEaZSNibsQSTuUIXNtsCgrTaDfJZllvn2QChovIkRe4d3MwYSy77K0qAl2DmzUWs5LMXpmM wuPEsBG87M5uUrs4ukLoMYlRpDzX79kAZF81pHRowhgXmh3TvMZO6L62Z/DvcMJYkr15er2+LP0 TEuDJWgIlGLdn6XpLDj8Z8lSorHPxwxPsqyFSmNwA8Ax3SKO/cpoJF4FayjOjKdO6QklsczlLqZ v/88n5iJxitmukzMlL/EF9XsiH3uwFxog9o+0Ye0dbQgmK5icjGEWk+K6WxmIpYQBYtWh31Iqvv 7DneR0yBj8Q8EcSqFWns3tm18drgaD3OIr49GYMb8wTIGnp21iJ9mrBoLcQhgLYc7lvTE8QlEcH aZQ9GnU+SGyIUlH+q9DN/elzGdJAemP6eHAXNIsmmEe4dZylXxRXZYko2jsn2g8lXEZWo+86q6r JdSTOu9g2Ge6KgIQKmhLlIDmUfFy6bVuMLUhc2U792XkF5V8n7OQVnhzDh6k4RU1lJqt7xkK9+P 4UmGGdQATYQdT/FzuYjE X-Received: by 2002:a05:6a00:2e20:b0:857:7337:5db8 with SMTP id d2e1a72fcca58-874dd9f1d6cmr9505601b3a.22.1789841401814; Sat, 19 Sep 2026 11:10:01 -0700 (PDT) Received: from phui-2.c.googlers.com.com (67.51.127.34.bc.googleusercontent.com. [34.127.51.67]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-877a94f8c39sm1190168b3a.28.2026.09.19.11.10.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2026 11:10:01 -0700 (PDT) From: Hui Peng To: David Sterba Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] affs: check affs_bread() return value in affs_truncate() Date: Sat, 19 Sep 2026 18:09:56 +0000 Message-ID: <20260919180958.1362943-3-benquike@gmail.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog In-Reply-To: <20260919180958.1362943-1-benquike@gmail.com> References: <20260919180958.1362943-1-benquike@gmail.com> 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" The extension block walk at the end of affs_truncate() does not check the result of affs_bread(): while (ext_key) { ext_bh =3D affs_bread(sb, ext_key); size =3D AFFS_SB(sb)->s_hashsize; ... affs_free_block(sb, be32_to_cpu(AFFS_BLOCK(sb, ext_bh, i))); affs_free_block(sb, ext_key); ext_key =3D be32_to_cpu(AFFS_TAIL(sb, ext_bh)->extension); ext_key comes from the on-disk extension chain, and affs_bread() returns NULL for any block outside [s_reserved, s_partition_size) as well as on a read error. AFFS_BLOCK() and AFFS_TAIL() then dereference it, so a crafted image with an out-of-range extension pointer gives a NULL pointer dereference while truncating. Every other affs_bread() caller in fs/affs/amigaffs.c already checks for NULL; this loop is the outlier. Bail out of the walk on failure. Breaking out rather than returning keeps the affs_free_prealloc() call at the end of the function. The remaining extension blocks are leaked in the on-disk bitmap, which is the correct trade-off against dereferencing NULL - the image is already corrupt at that point, and the error is reported. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM Signed-off-by: Hui Peng --- affs_validblock() was factored out of affs_bread() by commit d5de9fd594eb ("fs/affs: add validation block function") in v4.11, but the predicate it replaced was inline in affs_bread() since the start of git history, so the NULL return has always been possible here. diff --git a/fs/affs/file.c b/fs/affs/file.c --- a/fs/affs/file.c +++ b/fs/affs/file.c @@ -971,6 +971,11 @@ =20 while (ext_key) { ext_bh =3D affs_bread(sb, ext_key); + if (!ext_bh) { + affs_error(sb, "truncate", + "Cannot read extension block %u", ext_key); + break; + } size =3D AFFS_SB(sb)->s_hashsize; if (size > blkcnt - blk) size =3D blkcnt - blk; --=20 2.43.0 From nobody Thu Sep 24 21:47:55 2026 Received: from mail-pz2-f34.google.com (mail-pz2-f34.google.com [74.125.228.34]) (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 1C826385D97 for ; Sat, 19 Sep 2026 18:10:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841404; cv=none; b=V4lRN3bkcnnEGzTGIPq3POlGRA/V1YWE0F5ol/lEvS6mQlgWKZNJzZHXH8tx68p1TUspwhpXg1MNek/fraYYyVaTWLEE/JqXatT0AjRgeXZO6IXKWY4BH3h+qHoPinAU1efe5aAIcsGL6FVNTiUeDOZgsTNLvywD3HWO3iNzeLs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789841404; c=relaxed/simple; bh=b1Eqor/XA/1dclmoeTJ6useLZPuzRaNCBOEbwaWnw8g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qnEFHezivYH3GeyEtU2+4hwCfk+bzzOVJbUMOUIoIURDdykQ4mdehEqRD0vTQdD6Vuy+Akg1MAK0x9qxbXgy3lcr7n33lS98s6ES3RmcZgpG5oxLQpYR9iqjn7aE3eJcKwFxKaPo8KY3s4b5kqyJhBPX24wkPBXdm+X4tNOujw8= 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=oeAMenRZ; arc=none smtp.client-ip=74.125.228.34 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="oeAMenRZ" Received: by mail-pz2-f34.google.com with SMTP id d2e1a72fcca58-8748f34b1f2so1735123b3a.0 for ; Sat, 19 Sep 2026 11:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789841402; x=1790446202; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=giTwKDIwEU84jfLK5hnKcSoBAczq+bG+LFpvE2zAxq8=; b=oeAMenRZ7xVPh0avtvjRAr6BQ/MJNMqmvqxnPX0jSvo2PrjdwrTNFtOeUwit0Pr3dz HrCWojO7Foe6IWJjlAWx5Otnk0LqYX+sdFovVhWLbQu2JD3/lcr+5UHKOpikHsW6r7Bo 1Tb5sSa7dTcraUeA4Dx1U//V7A0bQUZdA/VuM7I6toFUNj5xPrbq+fPJIJSTAwE51sfH uGtDVqs8Tv3wZ20WBmM8qaLpSgE0fcAou71VJDqIBZ5dCN5UMhAtv8VVxjWuqV3alw9L MEqueXMhjG+c8RHCvrXNEYxNo8JU/Q1MGxQqgbjW1/P1pWcSFDyPfEa5E5q8p69sZQiW CHtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789841402; x=1790446202; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=giTwKDIwEU84jfLK5hnKcSoBAczq+bG+LFpvE2zAxq8=; b=f/jTUTzx9aODlmvoH/08YHTwq4q6YBmYhzW4VSVJyLvYgb7EsPrirS/lNH/aJffl7n MY5Rb/ljJVqClxrAJk5DxfP5M2C/ekmy+hbOG8yZaJ7tGOa6dkTv4ABhcDe2WR+jp0vx Di0mIsr4ZoNMf2nMispmhhRm3JVLUQzgszQozI1Mp9cT/N4SHHAh/UrDu4hKAoPEAAt7 IJFhtg/xl5PAMS9qrHiwbssOJQQd5xSMrlP/Y04gZEKUOyK0mYgYypPCTOy3xqGxBLDO hjpCn5/yLnbhAidW5e+AUlwErVQo2q02A8uZ7sU2DAxrFAyA2dqjnkd1eeVp4QBzvDbL Yuvg== X-Forwarded-Encrypted: i=1; AKwUvBxLVhFA6v2QntNKdBryvGqSyDXjv/e7/IblbtfNifDvDAmySqRLa89WA+poL/otuKDO3OlrOHhacl5ZPSw=@vger.kernel.org X-Gm-Message-State: AFuF++nsdzzzSmL8uLpBMrgGpbvgUZl3SW9+0LCh52mzo/VJs1TQbjbz DDFhnGrxyYgXGPuxpXgHwnDq/rdjReRbYfVT+3lOQihDpXifhixNTsjx X-Gm-Gg: AYBFou0RSWk4XBk9hsaq+eUVsrp85DgYSX+uap4QSqBEDMZUOosHYZCDQmassAyypDd Xz3wExgaJD2r3802y6ERnR3jkai/dphr5Mhtnw4UJfKXCASR0MC3z6GMw0TMuydaok+GUsKWI5W 0VDpyPO60SlmGyfpmrJMbbfbsoy+UndNo8LR8C8SZBlOtbAKu/b+VJNSgMILoWal3rAdubfPgqN cpWgEWkobW4R51p10LTpC+KwdyxdCS/P3J5Lz/MK24Dh+duKGsBOyOEk6NhaIyx6dsYX2UQwc21 g2edgONHcspn+h8OVJ7ZBLclZnfcqOSAB9hRDuJN9b5/NFSSBY0gyYik4t/sx6EPXz1HLs6tze9 3NwJDMth/2gCOkJ8EbNtPec5h/grMwXweyUAt1595tuwNpZ3P9P6lxJR4TMlWKIUjGVRW4dvjK9 uz6OACrDh2kbATQ6dxi3sPczMLkLAz4tmfolpBoL/NmAk033qnNiWRdSS+RVYomfXK05Wcirl5s uAegtRIjIVqJBj+FYFwy1ovQX0MB7E5fdz1GIS0h9nXYFUBW0Ho1272UyHfYZEhvMhMOVKf/C7y FWBYhOHloQ== X-Received: by 2002:a05:6a00:1d99:b0:873:5267:dfd0 with SMTP id d2e1a72fcca58-874dbee3a93mr8677777b3a.5.1789841402439; Sat, 19 Sep 2026 11:10:02 -0700 (PDT) Received: from phui-2.c.googlers.com.com (67.51.127.34.bc.googleusercontent.com. [34.127.51.67]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-877a94f8c39sm1190168b3a.28.2026.09.19.11.10.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2026 11:10:02 -0700 (PDT) From: Hui Peng To: David Sterba Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] affs: validate the allocation goal in affs_alloc_block() Date: Sat, 19 Sep 2026 18:09:57 +0000 Message-ID: <20260919180958.1362943-4-benquike@gmail.com> X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog In-Reply-To: <20260919180958.1362943-1-benquike@gmail.com> References: <20260919180958.1362943-1-benquike@gmail.com> 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" affs_alloc_block() applies the same too-permissive range test that affs_free_block() did, and then performs the same arithmetic: if (!goal || goal > sbi->s_partition_size) { ... goal =3D sbi->s_reserved; } blk =3D goal - sbi->s_reserved; bmap =3D blk / sbi->s_bmap_bits; bm =3D &sbi->s_bitmap[bmap]; if (bm->bm_free) A goal strictly between 0 and s_reserved passes the test, underflows the subtraction and indexes sbi->s_bitmap far out of bounds, and a goal equal to s_partition_size overruns it by one entry. Unlike the free path this is not driven directly by on-disk data - goal is derived from inode state (i_lastalloc, the last allocated block, or 0) - and I have no reproducer for it. It is the same defect in the sibling function though, so fix it the same way, with the helper that already defines the valid block range. Keep the `if (goal)` guard around the warning so that a first allocation with goal =3D=3D 0, which is the normal case, stays silent. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: LLM Signed-off-by: Hui Peng --- Behaviour change worth noting: goal =3D=3D 0 previously took this branch via the `!goal` test and now takes it via affs_validblock() returning false (0 < s_reserved for any mountable image, since the root block alone puts s_reserved at 2). The outcome, goal =3D sbi->s_reserved, is identical. No reproducer for this one - please treat it as hardening rather than a security fix, and drop the Fixes: tag if you would rather it did not go to stable on its own. diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c --- a/fs/affs/bitmap.c +++ b/fs/affs/bitmap.c @@ -133,7 +133,7 @@ return ++AFFS_I(inode)->i_lastalloc; } =20 - if (!goal || goal > sbi->s_partition_size) { + if (!affs_validblock(sb, goal)) { if (goal) affs_warning(sb, "affs_balloc", "invalid goal %d", goal); //if (!AFFS_I(inode)->i_last_block) --=20 2.43.0