From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 2E8887B3E1 for ; Fri, 26 Dec 2025 00:54:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766710450; cv=none; b=eUNEsWF+xPjWVAotcwebLJoTWh0jJ1SXJZ8bSNw8YsnmqUSzkK/CtlE3Mzg14bNcuMQehqZIPfciKCKRCsrHcxOtVjhsOCJP+Bb+Ixu3WkUQIp6/LQ+7SbJbBTonT8LJFIqLUjccw+owd1kiZSqV8NWm0H8peOsgwrsQ63X6SM0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766710450; c=relaxed/simple; bh=i5COWy3rfZwIgUNxrI4GAwaQqLJsqNDLuisCM/dK6f8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b63jDS4/TzswmmMmXvCprsI5R23oTP8huZ593DE5cpHXeqS1vVUIgAF/42AHl626zVH4hAwtG0mwpiBnuosW5VNJ6BUFiNElVYq3k7H3JVIAv29VG+iQ6osQEB3tGOlOaIbAVrlea7wolHeh5HhppBOCQtunh8V7cKPaB7vz+Hk= 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=G5kL6WxH; arc=none smtp.client-ip=209.85.214.180 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="G5kL6WxH" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-29f30233d8aso82469905ad.0 for ; Thu, 25 Dec 2025 16:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766710446; x=1767315246; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=0Nz8Tjp3AaOWOXlLmwlKJ8QCQ6dId4zIiZlrgYittUg=; b=G5kL6WxHOM2FDWL9Hd8D7Dkw/R4dqp8FGwi5pRN0CHb7wlAGTCKIzpRBf3Lkw4uamt bxivJcWkCsZAK+kS4HMbLIAjsYoJg+TCayiAjjtO4rOAExWIL3Ox74pW2U/VRDqiAOh1 zZMe3GPBZpJpsz3mpvk3NYVvHVmuKibyjrOHjQBR+QZuN6MJ87zCz5X752BIUZM0+bK5 4SZM8mpYsKbNSzvzHMllc4GuNJw9WZze4dz3H3zvhkfcRwTEREwWPLCtJO3lVU2bFSMq yIBuj3G6BTY2CSDKHm+eGnzeoV0GyfbcEtwitlfTetcXcJagrt7ZzyRZGNHzWAG8Z52t 3GDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766710446; x=1767315246; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Nz8Tjp3AaOWOXlLmwlKJ8QCQ6dId4zIiZlrgYittUg=; b=ugLsl/SyFpITOsQ4jthAVJiv6Z8OwOJLWb/jCdkG2rQWxNDiU3/9hRqTvGJSIzvWcd mS8s4evRLSHqocd/lx+YTsZOmLoLo8VjeIrR0bHMzGg6sCTYX8DSFTA+Uw+fIbKygYAu C2qhhXq/81QPkaoEHAIfkr3ORrDWvEKAhhaqDqQPQw/UBMhHGr+aBdmQxvypEWBV64tI GfuPMlHegEWdDaRWln7xBuW0pnycrtGDFxhiozK1EWvrkuJSzqYV3jM4eV1PkyeWMfn1 X9AqRwwrw5KttU5PCsloHjocfqcFau9T0cQxQAoruCBpiGoRxE0j6Ostouxa2vG/7BJe bcLA== X-Forwarded-Encrypted: i=1; AJvYcCUA5CNM9TYCogr5P+ykjr0Q1+uE2OCUNT99cF1JO9676+IXOjXTF4RUQ6s7Fdh/PNzNDn7JRov3kZxZw78=@vger.kernel.org X-Gm-Message-State: AOJu0Yzr1MizJqZwbRCLzjO/4Zf9+FF+Ps5eQFubY50qWoVPbfz08z5F RMOJrqswxqRB6ylVTL5ww1mIw6E0/5XgtosjMYwNqW6e10T40r6fqpV8 X-Gm-Gg: AY/fxX5Hxa+dNVk0Nz+//+u4Rd+qgdDwZU42A85kAxdsLS+U+xJyZrrji7ucjQKa9Og m+aD3QJIDadpUHnv+2cjpbFACQNdBWTLnxgxRi/1oKrujwnDUQ+NkT1hbcA9h5P6Rg/fkCeVBzt BTAF1TZXXBBoaEIEFu84Bz2uacSpnFr4iZIjnhegeHaXPKTOWVGgUEDKS/TzY2U6aAiM1peL3qC BuDgHur0dbOMhxMvp7kSMUkSaAci/k+9VsW6g2//vCjTr37B0lU5iBdKdc2FqGqwfp+ql6YPgqB 2qrkGGgDHOaazX9ENiT+osna7wRiFuCo+n79hOYoQISFLP4MQDVcjQXVOZg/zFQHYETPY7a8IE+ 8B11WRjQV281GCUTdgrP9luTxtbKUr2hv4CojdsHtgnRWDWEJyqdSF0EWekBSyGbPxuSG9q34Dm KYTSA213aD8A== X-Google-Smtp-Source: AGHT+IGaDsT0j4q8/ZSFFbw2xdc1M9VAnGq5qpd7JQCuRHzrrYcXtXjqAkcYXXbP4gPMX3j0h85Juw== X-Received: by 2002:a17:902:ce82:b0:2a0:f469:1f56 with SMTP id d9443c01a7336-2a2f272b393mr241519525ad.31.1766710446312; Thu, 25 Dec 2025 16:54:06 -0800 (PST) Received: from localhost ([2403:2c80:6::30e5]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7a8442edsm20380428b3a.12.2025.12.25.16.54.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Dec 2025 16:54:05 -0800 (PST) Date: Fri, 26 Dec 2025 08:53:54 +0800 From: Jinchao Wang To: Jan Kara Cc: Theodore Ts'o , Andreas Dilger , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com Subject: Re: [PATCH] ext4: xattr: fix wrong search.here in clone_block Message-ID: References: <20251216113504.297535-1-wangjinchao600@gmail.com> <4msliwnvyg6n3xdzfrh4jnqklzt6zji5vlr5qj4v3lrylaigpr@lyd36cukckl7> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Dec 18, 2025 at 04:39:08PM +0100, Jan Kara wrote: > On Thu 18-12-25 09:40:36, Jinchao Wang wrote: > > On Wed, Dec 17, 2025 at 12:30:15PM +0100, Jan Kara wrote: > > > Hello! > > > > > > On Tue 16-12-25 19:34:55, Jinchao Wang wrote: > > > > syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1]. > > > > > > > > When xattr_find_entry() returns -ENODATA, search.here still points to the > > > > position after the last valid entry. ext4_xattr_block_set() clones the xattr > > > > block because the original block maybe shared and must not be modified in > > > > place. > > > > > > > > In the clone_block, search.here is recomputed unconditionally from the old > > > > offset, which may place it past search.first. This results in a negative > > > > reset size and an out-of-bounds memmove() in ext4_xattr_set_entry(). > > > > > > > > Fix this by initializing search.here correctly when search.not_found is set. > > > > > > > > [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 > > > > > > > > Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set) > > > > Cc: stable@vger.kernel.org > > > > Reported-by: syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com > > > > Signed-off-by: Jinchao Wang > > > > > > Thanks for the patch! But I think the problem must be somewhere else. > > The first syzbot test report was run without the patch applied, > > which caused confusion. > > The correct usage and report show that this patch fixes the crash: > > https://lore.kernel.org/all/20251216123945.391988-2-wangjinchao600@gmail.com/ > > https://lore.kernel.org/all/6941580e.a70a0220.33cd7b.013d.GAE@google.com/ > > I was not arguing that your patch doesn't fix this syzbot issue. Just that > I don't understand how what you describe can happen and thus I'm not sure > whether the fix is really the best one... > > > > in ext4_xattr_set_entry(). And I don't see how 'here' can be greater than > > > 'last' which should be pointing to the very same 4-byte zeroed word. The > > > fact that 'here' and 'last' are not equal is IMO the problem which needs > > > debugging and it indicates there's something really fishy going on with the > > > xattr block we work with. The block should be freshly allocated one as far > > > as I'm checking the disk image (as the 'file1' file doesn't have xattr > > > block in the original image). > > > > I traced the crash path and find how this hapens: > > Thanks for sharing the details! > > > entry_SYSCALL_64 > > ... > > ext4_xattr_move_to_block > > ext4_xattr_block_find (){ > > error = xattr_find_entry(inode, &bs->s.here, ...); // bs->s.here updated > > // to ENTRY(header(s->first)+1); > > if (error && error != -ENODATA) > > return error; > > bs->s.not_found = error; // and returned to the caller > > } > > ext4_xattr_block_set (bs) { > > s = bs->s; > > offset = (char *)s->here - bs->bh->b_data; // bs->bh->b_data == bs->s.base > > // offset = ENTRY(header(s->first)+1) - s.base > > // leads to wrong offset > > Why do you think the offset is wrong here? The offset is correct AFAICS - > it will be the offset of the 0 word from the beginning of xattr block. I > have run the reproducer myself and as I guessed in my previous email the > real problem is that someone modifies the xattr block between we compute > the offset here and the moment we call kmemdup() in clone_block. Thus the > computation of 'last' in ext4_xattr_set_entry() yields a different result > that what we saw in ext4_xattr_block_set(). The block modification happens > because the xattr block - block 33 is used for it - is also referenced from > file3 (but it was marked as unused in the block bitmap and so xattr block > got placed there). > > So your patch was fixing the problem only by chance and slightly different > syzbot reproducer (overwriting the block 33 with a different contents) > would trigger the crash again. > > So far I wasn't able to figure out how exactly the block 33 got zeroed out > but with corrupted filesystem it can happen in principle rather easily. The > question is how we can possibly fix this because this is one of the nastier > cases of fs corrution to deal with. The overhead of re-verifying fs > metadata each time we relock the buffer is just too big... So far no great > ideas for this. > > Honza > Baokun explained part of the process in the kernel space. https://lore.kernel.org/all/d62a25e9-04de-4309-98d1-22a4f9b5bb49@huawei.com/ I analysed syz-reproducer and add some userspace details: - original filesystem state - file1: - inode 15 with File ACL block 33 - file2: - inode 16 with data blocks 27–35 - actions - syscall(__NR_creat, "file2") - syscall(__NR_unlink, "file1") // panic happens here The original filesystem state is already corrupted, with block 33 beging referenced both as an xattr block and as file data.