From nobody Fri Apr 3 04:38:35 2026 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 D8014217704 for ; Wed, 25 Mar 2026 00:44:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774399445; cv=none; b=KPnen0sHMzh9uTogd/bpr1Hm+pjqjeBQeAYfUyMIs3X65w5vPQ6Zo43VEid4yM2w2uA/fwZrU2d8iN+zav9ZtQE3KRnuHDk8C9jh0Of21TSnPmPJFQMP4wf6GX70HeHgWF6VdATNQZuO5r5uYFK/mLZP/PSPOkHVHHP5iqxLZGw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774399445; c=relaxed/simple; bh=JLF9UZfXxMEmFArZnVwjL4KjhH5VxvRV1eSsRU9KZpk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jjIRQPI6V7w57gORp+Q4yt7EXn8CRlDXhxc/bJRUHdSbwr0bN52PpahC++HVcpHO1fp8xj3gifJJghYBElRMhEBJ9Bs/+YRK2GfNKxn03LB7ffcrisQvzAIAut9NFpvL5c3TRpOlAaxCsIVTT5KzDaXnFxMa5iAHEhq6NW0m8VQ= 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=gh80qZks; arc=none smtp.client-ip=209.85.214.170 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="gh80qZks" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2aaed195901so25173745ad.0 for ; Tue, 24 Mar 2026 17:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774399443; x=1775004243; 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; bh=KdSSlv0LVdyZD0+zj1U8PtUbtcqZsX166xUNgywcviU=; b=gh80qZks7xtAwFuN6XKzbKCQUPazOHz1wNDGGLqup+WrcOFLvwabb/J4esK//kgJmW JPG5IGJh3T+THqAO5M9Dz+zBrBwCR2KHvFNjkGa+E0o+M2DsD1BpNYGgSBDB0rQREJPf /qbRspZaQeENQ32nMEME0ZuHrPgsqFtX0SomCeJU0KUb+15gW+p9GJK5Y5tqUx7vm9vW pqAtcx/zzFxMC60F9BN+0fFOc8WpUTmGJj7SFfZHYK2EmD28M/rJkTpn2IIMhGp7cwiM 5FdpmioH5rdprtmEOP9hLxvs2AnSsN/3xe3cQxvS/X+QxUPyKWuoWp6SyyB/K3EslEN9 4reQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774399443; x=1775004243; 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; bh=KdSSlv0LVdyZD0+zj1U8PtUbtcqZsX166xUNgywcviU=; b=Iy4Ck4qAl4EfI67KNUb1aSruUgVFGjCr+etCreaS6+Kk4LDY/jTGNRBYePsWIZbZ5I 184oe7UUYXo1KQS7mm+4mcRev8O0cZmD4DbiWtflnOjdh+3Zd/LkBU45knLe5pfHRdad uc45l4KnlshN9Is+Tqj59Q0QTf7XJIQadL52m4LzPDjUj93qecmaJVSKCESGeXQi2W8s geoaHU8/PqIOq7vDbKHOYZ5H4531v0NKWXr7WW59B2rqBMqxuZqEaJrdzDzKjSia+iC2 kgFOBSZlIZtFLIBhxLgqInHMpfvoHEz84vddO40ReVWP0QFPgFnD4vdnZ8dQzgFz2VcZ LGBQ== X-Forwarded-Encrypted: i=1; AJvYcCV9LYxzL80GIRVFTZOIFULtfrEtoEIRAIv6xMrjW3K2rkzEFoDKszcs8SMlv2uwrf/YudKEDAYz59U6wUI=@vger.kernel.org X-Gm-Message-State: AOJu0YxnYLg51M1YZ8e9WyxZTQYkTDr09QEtpPykkre1KPGICzTN+zJ5 yFmiQU3q7vLDhtIH8hZvHjJZKVoGzYeo8yo7S66e1l9WiYL8bhFhaz2n X-Gm-Gg: ATEYQzzpVDxQDZX8Il4qFh9RH5Mr6Ftt9xYZ/80Xi8/EXrytGJbXU7Q1c3jgcb5197P 4+538jRb9O1Ziffag0S88g6pxLrYbMVWbgvD7qMnvrR7QrJTCeGxwAli3Qx0YFc2ygb+vPHSKoH 0Zs/MhqVWgpZHXJ9PzjYFCngBRqCnX1MKQ8yYzwLfKNQGPsc7ptgXIm8mGXLqG2873+Lic+i4pN WbhPrcE9WUrn9o4YGFElmI8g3ADvJ1OCKQH7+fP+bDG5joGcdVGRNJDCUVZCyJTTC4/QxGsj8hJ sLti6mbRnoxR0tC6nIFByv9/8IuF1LNdF6NjHsCZ3nEebNPezzOvqZGYCjsIXUIFgf8aNEU4aQp 5NKT2EmyKbfKQ8YXVmzboZFhXjk2YkWEHEewyYEVG4zi7vwVsIdssstNxn3lWI4VEsR7nO9Zz9s lI75Un86moQUhtWBpbCVba9HlnU8u2IhrVxZ65pHqXH1qzeYP0GP0PF+pwe0+msXbKODuk8g8= X-Received: by 2002:a17:903:3c30:b0:2b0:5fa0:3afa with SMTP id d9443c01a7336-2b0b0af58a4mr15324275ad.27.1774399443065; Tue, 24 Mar 2026 17:44:03 -0700 (PDT) Received: from kernel-fuzz.. ([103.172.182.26]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0836554acsm207457015ad.51.2026.03.24.17.43.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 17:44:02 -0700 (PDT) From: ZhengYuan Huang To: dsterba@suse.com, clm@fb.com, idryomov@gmail.com Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, ZhengYuan Huang Subject: [PATCH v3 3/4] btrfs: balance: fix null-ptr-deref in btrfs_may_alloc_data_chunk Date: Wed, 25 Mar 2026 08:43:38 +0800 Message-ID: <20260325004339.2323838-4-gality369@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260325004339.2323838-1-gality369@gmail.com> References: <20260325004339.2323838-1-gality369@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" [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache =3D btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type =3D cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk(). If the lookup fails, emit a btrfs_err() message identifying the affected bytenr and return -EUCLEAN to report filesystem corruption instead of dereferencing NULL. The caller already treats negative returns from btrfs_may_alloc_data_chunk() as fatal errors, so balance aborts cleanly and reports the corruption to userspace. Fixes: a6f93c71d412 ("Btrfs: avoid losing data raid profile when deleting a= device") Signed-off-by: ZhengYuan Huang --- fs/btrfs/volumes.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 65df8652d760..e89eb5c1dbc5 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -3597,7 +3597,12 @@ static int btrfs_may_alloc_data_chunk(struct btrfs_f= s_info *fs_info, u64 chunk_type; =20 cache =3D btrfs_lookup_block_group(fs_info, chunk_offset); - ASSERT(cache); + if (!cache) { + btrfs_err(fs_info, + "balance: chunk at bytenr %llu has no corresponding block group", + chunk_offset); + return -EUCLEAN; + } chunk_type =3D cache->flags; btrfs_put_block_group(cache); =20 --=20 2.43.0