From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 F0B0E269CE7 for ; Sun, 26 Apr 2026 20:16:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777234572; cv=none; b=bBjxHPBGxIoXYE4wUrrobF8BrGKYHFrM6d8shr4sxAibH1/iNUXjzniQVGiDJHktx0nLPbJP9pI19Tc1WDaVJjQUMM6x9uBXwzswm2VXQpOW4V3dYW3jdQvnSPHnJ+TmbeRl7OpLsTRjKJT92TC7cNVxi6m5dcBU8CsU3uOMMNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777234572; c=relaxed/simple; bh=0cBDJDVsverrJm5TX4gD92HaBBqI7XiWHStBQDqbsKE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gObVI1FnxPpXlht9Zw7qF5a8YhuUbHK05phbdlKI51/0DLDHRviVILycrRfRZvupJej9skWf8CSYuoh7h1knuby3p43ATnhjGkiDAyutVfyc+lqPggGMeuODDt/Gj+twkBAqpaq+yB1gjhNQ8mdt8Uc4tkkGNAKhSqzmTlw5Ku0= 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=hKEQMjLh; arc=none smtp.client-ip=209.85.128.50 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="hKEQMjLh" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4891c00e7aeso68901985e9.2 for ; Sun, 26 Apr 2026 13:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777234569; x=1777839369; 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=YEG1xBF5/17YlnXXV6ISynHTyhtqMCuuiWpFweQNv/U=; b=hKEQMjLhqvnSoBhDdrqyQPRukKLdNV73u9KYv81wGHKfjRlTGibD8sPeqYx3lgkN/e Ya2B1kInDpBVhEWGaf4/U6I3nYF5WBVhOTG7DQ4dy8ZkWuGbJinrkvo8H8Yi51Zj7OEO UxfYmBm7RP3lnXrA+2/DP+81yCXM+GTn8mKd26cQiWcQIcgYoSlOpoBKPvVxJ74b5umW tyvnrmzRRvmZZ07tBu6JsLehOqKUv9fGtie6DsB+ZxPQejrW9a2nbx1rs/6+9nJOdUy6 TmRUKZ8GZL3gJ5cTzkkReFDal3EB5k/N6ChP/v9dpR9Ixx2ho0iX38GBSo6Ata0Pk3/S oWpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777234569; x=1777839369; 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=YEG1xBF5/17YlnXXV6ISynHTyhtqMCuuiWpFweQNv/U=; b=HT6d9AnO6B6CKdBe+RL0KIDah7r/oFVk8iBd4+DUE2v++WM6yX5wfOwlH27HgxliTU 2BS1PShRkwk6dZJZ/UCXh+6F8MJWRLNq8BiVMVAuHDYMBj0cTGn8FCHd1txYYDrc6WiH XLQNXxmgfxWlVCmA49YFFA50Up07jWVDR155sEVVWDFekC7qO0J0cQHwGamEqCqkjF75 iSln2k1FA4k6MkbyWNo6mB/LuT+mXdUoLJ4qby4b6hD/e+7mxlK8Bw249EyoI8P1GN7y Jz0WL/sSObF8w6W8sXhe2nI4lG7nu2fJ5Ws5gPPCix7CAIaaAKTw2QCsE/iEgRnpusv+ ulaA== X-Forwarded-Encrypted: i=1; AFNElJ8HE91/RM/9pYW6pyDhq5yMwgLRbekglrX+/3i9hyCzG0y0h/MfH2cyY6nJno9AdnFp515YlhY5u6C0Vz4=@vger.kernel.org X-Gm-Message-State: AOJu0YzPN6XDPWFkYqmYLaDEwBRDx3LDstNMwWPn5xTDO204rQf0gNGq ZOr4nRXRdsyRyGmb5u74DX6vDNpKbclMleZHfCBVV0XmEFa9BLfHEx6w X-Gm-Gg: AeBDieugq3YznKjrgUAMm8H2NYUHEZsj+dE+I0qiSbbLHk+O3ZDmhdnN6n/c4q9HODW eSRIUclx5gujwINxVdMr7llGcA4WoWg7mCEeo7jhBkGxw35Z+cgBgit8qKlFwVRWXJjcItMYV5D S4WZe5jBRe5C2EzkUMeVvXEI5yG2Dg6XdiQkUcJgmKxvrtufK8fO0in2cHrY6mfxZbq1AO2CAn7 pQL3Zo1uDvY3ZVnndeVk5eZ39sM/Mors1EaFJIQo2sX2pyYey2T8tTUIKQCVDh3ozqUfATYsuai 0RyYcWHejoFDzY+oCCP6nSMzro1CX/JuuF6qEjX2Ah9CLuoo62oNX3TlIbrn3GxQRyat6BVZKJo cr0rdRGpZk0w6H0M8iYkw3UceHN0T2Kgd5Lcy5mS/9eLrPW0Zj2FXzkzS1hZjzF60Y+JkXlMMce nDJ8a/jHqxMxtZybcQZHLCi5kDY1HOMM3T X-Received: by 2002:a05:600c:3213:b0:489:149a:f9e6 with SMTP id 5b1f17b1804b1-489149afa07mr257254935e9.28.1777234569033; Sun, 26 Apr 2026 13:16:09 -0700 (PDT) Received: from localhost ([145.40.214.139]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fc0f82bbsm1272653495e9.3.2026.04.26.13.16.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Apr 2026 13:16:08 -0700 (PDT) From: Teng Liu <27rabbitlt@gmail.com> To: linux-btrfs@vger.kernel.org Cc: dsterba@suse.com, clm@fb.com, wqu@suse.co, linux-kernel@vger.kernel.org, syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.co, Teng Liu <27rabbitlt@gmail.com>, wqu@suse.com, syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.com Subject: [PATCH v2] btrfs: replace BUG_ON() with error return in get_new_location() Date: Sun, 26 Apr 2026 22:16:00 +0200 Message-ID: <20260426201605.36626-1-27rabbitlt@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260425061214.235982-1-27rabbitlt@gmail.com> References: <20260425061214.235982-1-27rabbitlt@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: 8bit In get_new_location(), BUG_ON() crashes the kernel if the looked up file extent item has any of offset, compression, encryption, or other encoding set. The data reloc inode this lookup targets is populated solely by relocation's own prealloc and writeback paths: - insert_prealloc_file_extent() memsets the stack item to 0 and only sets type/disk_bytenr/disk_num_bytes/num_bytes, so the four checked fields stay 0. - insert_ordered_extent_file_extent() copies oe->compress_type into file_extent compression, but the data reloc inode is created with BTRFS_INODE_NOCOMPRESS, so compress_type is always 0; encryption and other_encoding are reserved-and-zero per the comment in that function. So observing non-zero compression, encryption or other_encoding here should on-disk corruption. A malformed image can reach this code through a balance operation and panic the kernel. Replace the BUG_ON() with a return of -EUCLEAN, the established error code in fs/btrfs/relocation.c for filesystem corruption, and pair it with btrfs_print_leaf() and btrfs_err() as suggested by Qu allowing dmesg to log the necessary information. The caller in replace_file_extents() already handles errors from get_new_location() by breaking out of the loop without aborting the transaction, so no caller changes are needed. Reported-by: syzbot+3e20d8f3d41bac5dc9a2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3e20d8f3d41bac5dc9a2 Signed-off-by: Teng Liu <27rabbitlt@gmail.com> --- Changes in v2: - Pair the -EUCLEAN return with btrfs_print_leaf() and btrfs_err() so the offending leaf is dumped to dmesg, per Qu's review: https://lore.kernel.org/linux-btrfs/6c54901d-5e07-4c46-9553-997b28c93b86@suse.com/ - Expand the changelog to argue why non-zero compression/encryption/ other_encoding in the data reloc inode imply on-disk corruption rather than a kernel bug. fs/btrfs/relocation.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 1c42c5180bdd..bba28866df1c 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -814,6 +814,7 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr, u64 bytenr, u64 num_bytes) { struct btrfs_root *root = BTRFS_I(reloc_inode)->root; + struct btrfs_fs_info *fs_info = root->fs_info; BTRFS_PATH_AUTO_FREE(path); struct btrfs_file_extent_item *fi; struct extent_buffer *leaf; @@ -835,10 +836,16 @@ static int get_new_location(struct inode *reloc_inode, u64 *new_bytenr, fi = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_file_extent_item); - BUG_ON(btrfs_file_extent_offset(leaf, fi) || - btrfs_file_extent_compression(leaf, fi) || - btrfs_file_extent_encryption(leaf, fi) || - btrfs_file_extent_other_encoding(leaf, fi)); + if (unlikely(btrfs_file_extent_offset(leaf, fi) || + btrfs_file_extent_compression(leaf, fi) || + btrfs_file_extent_encryption(leaf, fi) || + btrfs_file_extent_other_encoding(leaf, fi))) { + btrfs_print_leaf(leaf); + btrfs_err(fs_info, +"unexpected non-zero fields in file extent item for data reloc inode %llu offset %llu (offset/compression/encryption/other_encoding must all be 0)", + btrfs_ino(BTRFS_I(reloc_inode)), bytenr); + return -EUCLEAN; + } if (num_bytes != btrfs_file_extent_disk_num_bytes(leaf, fi)) return -EINVAL; -- 2.54.0