From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.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 35A1F1F4168 for ; Wed, 25 Mar 2026 00:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774399432; cv=none; b=kiTsK80rMcyek9WD2HyN3PB0IpnwHVKKdQKUfMLebZbgZ2o4+a2rX0iyXZdC7Hzm743N5W3F0ZgU64J4x7GHcFs+mAlCBGSvMa1HV9CgUyPrji29dSLngs/YIWSjSYWd9srdFTnh0BKYJbU0jFcC32IE1szO2o1RSrMbWG83SQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774399432; c=relaxed/simple; bh=2ht9qQDNfdrLHS1FvPgF2fZP+ton6311epPWZ2Vj6zg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=tDppKEmj4zrmRBkFo1laWVH8IKQ9w6G4+NpPZ8KoeqfghgNYq9eDIQD7NpqUg60GRF5SlmQCMueMHSbYTJGEbNNUFF0cG/JL1kM0g0UhMqu/WbU7nasOioVAyVLHL3qoKNOWTBE0PAkvb88htoHR2ikvhYyGtaVMkcX/pDErseE= 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=Nw9Ef1DA; arc=none smtp.client-ip=209.85.214.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="Nw9Ef1DA" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2aaed195901so25173155ad.0 for ; Tue, 24 Mar 2026 17:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774399430; x=1775004230; 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=4U9wgFx4r1OB3Oda4Pvq16N+UuKhewRZ0htJHghmz4o=; b=Nw9Ef1DAZcAlxzXgw8RBOOnDEap7VzMJoao3/VfqyfQdxKEJg7vaRN2NPOndVWa8nU HXP/I3e1RXPEx2YnFt2GZS54UF/N0HEnjs3vvjlA/oNVSxzrL53IFSw+r6lUJV3kIysH StQd8GpY0FdDujp/wAAL4N0aHyeEhH4FuTAhh9OY43VeEvi4VVOWzY7g58o5PPcUc+iE CbuQv80pUXlmnK4w+XN7FJZqNDwk4sRqs324aPzOu3PhCLnsbWT2GGRoRMuQyNlD2xID QrCdYhMYr55dnLCiLF5fQhdZ8WGy0pZu/NcoCl3G+IuwNYEeiDMnQVMDPglSS8rGwSn4 eZ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774399430; x=1775004230; 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=4U9wgFx4r1OB3Oda4Pvq16N+UuKhewRZ0htJHghmz4o=; b=knaiEEmyaU9wBTm2xTCNU6IxedW43qJhghl8A3pNDt6MGLF0YqlC2EaNGm17Wblnll DzLrYt119+08Z7xgGQNkPwxrmXD8X0mIT2LnXT2SQccrGEbWFkMh9I4gXINVUkGLLJsp 3dnb6DLrJGyuwFqPr1b0UFzH0PzkBB3BbOK8g32Dtdq4yCg+si9xpXNn0KYxAgMLTaEX u2ChZO3xbbkw85PJAJIdh88kMU1FwvLgAdrtA5XcpfHWxbOEeIISfrHaRYSjeSdTTrXy Ju4iTbSZq6ejpmittSWEeJ747FlhaR6biCqBxSv/mQ3WY4z4Q5nzFnEhJLy6jw+sGDze IMTg== X-Forwarded-Encrypted: i=1; AJvYcCUW2waQUj/OvrfhQ7iEjap92jxA20LsfyAEW6JOQxmGL2bN9WPO2owrI8FJ28owtgt8/1GdzDLbM+ttASI=@vger.kernel.org X-Gm-Message-State: AOJu0YzPDzjexywKQDJ16MIryAqjvVnQnTEfc64WkIjkR0IkBkJJV+hm qZCHhEf8SggqHa9zVO0fkH9UoA7XUzN6uEml0EIJ/aRrBRCiSiGYe2qq X-Gm-Gg: ATEYQzwr3NmngX6+tYGncySe4XM7HP8M5eSjXtsfS+WEVNTl0G8uoh4iiP/HWh0Jmlr pGjXzdP3aOJDgUZY0NVpcj/bpC7YHxUtw3VhLKxQpP4O558lI8lngE/6UtdWY849wgqrgA6gLr9 B6f4w3Ut6naXJxly6yBPQN6bE5nA4gZLVB8VJKsQb8Suq2SxLu8ORCEWGqdQzhYKGoTa3S349UU hGySpLhX/LlNvZqnepvYxpiCX28bO7335if0CnTpTq6kkhkr1/hEZ2U6V+rmgt/LVYnhHH8wBA/ vfZbUi1dtcJiA+U2AipgwB7XFw0YEttHKl9uc477ejzxjiU7sy/f5Kl+p0KnCZr0LOjd1e1gRpy N7L6L3FMcCluKGiiv1SAgf59qZLCyxgcDGBYpb3W/zWLnUwOyE2EEqkhyD/2vpvPgqQrRYZaEVV BBSwOB03YQIfVLvQ973+3COdC9D3o0O1LAdVOwv/T9No+ivLIiY4/Ba8QxissqZZqGQ6KztXQ= X-Received: by 2002:a17:903:2344:b0:2b0:9a6f:c3b with SMTP id d9443c01a7336-2b0b0b270f1mr17192125ad.37.1774399430424; Tue, 24 Mar 2026 17:43:50 -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.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 17:43:49 -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 0/4] btrfs: fix balance NULL derefs and chunk/bg mapping verification Date: Wed, 25 Mar 2026 08:43:35 +0800 Message-ID: <20260325004339.2323838-1-gality369@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: 8bit This series fixes three NULL dereferences in btrfs balance paths and the underlying mount-time verification bug that lets the corresponding chunk/block-group inconsistency go undetected. The balance crashes happen when metadata corruption leaves a chunk present in the chunk tree but without a corresponding block group in the in-memory block group cache. In that case, balance reaches code paths that call btrfs_lookup_block_group() and dereference the returned pointer without checking for NULL. The first three patches harden the affected balance paths: - patch 1 fixes chunk_usage_filter() - patch 2 fixes chunk_usage_range_filter() - patch 3 fixes btrfs_may_alloc_data_chunk() They are kept separate because the affected code was introduced by different commits, which should also make backporting easier, as suggested by Qu Wenruo. The fourth patch fixes the mount-time verification side. Based on David Sterba's feedback, it now explicitly relies on the mount-time context and uses a lockless traversal of mapping_tree. check_chunk_block_group_mappings() is supposed to verify that every chunk has a matching block group, but its current iteration starts with btrfs_find_chunk_map(fs_info, 0, 1). If no chunk contains logical address 0, the lookup returns NULL immediately and the loop exits without checking any chunk at all. As a result, the corrupted mapping can survive mount and only crash later when balance reaches it. This series makes btrfs reject the inconsistency earlier at mount time, and also hardens the balance paths so the corruption is reported as -EUCLEAN instead of triggering NULL dereferences. [CHANGELOG] v3: - added a new patch to fix the same missing-block-group NULL dereference in btrfs_may_alloc_data_chunk() - patch 1 and 2: - changed the bool return flow to explicit int error propagation - used ret2 for the nested filter return value in should_balance_chunk() - patch 4: - reworked the changelog based on David Sterba's feedback - clarified the mount-time context for the lockless mapping_tree traversal v2: - split the two balance filter fixes into separate patches - reworked the chunk/block-group verification fix so the last patch addresses the case where check_chunk_block_group_mappings() does not actually iterate all chunk mappings ZhengYuan Huang (4): btrfs: balance: fix null-ptr-deref in chunk_usage_filter btrfs: balance: fix null-ptr-deref in chunk_usage_range_filter btrfs: balance: fix null-ptr-deref in btrfs_may_alloc_data_chunk btrfs: fix check_chunk_block_group_mappings() to iterate all chunk maps fs/btrfs/block-group.c | 24 ++++++---------- fs/btrfs/volumes.c | 63 ++++++++++++++++++++++++++++++------------ 2 files changed, 55 insertions(+), 32 deletions(-) -- 2.43.0