From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) (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 D563C3BBA03 for ; Fri, 17 Apr 2026 10:12:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.72 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776420776; cv=none; b=csvh9lrRL4hnRCsBM/tR1h6vsa9RJieyizAugYLzfMUacEpaK23GtwgEvFo9Lu+vXKbj2Ebg7KAai2azWmvaDyw7TPSfiYtQUr4aiPugvg3kd+c/a//Y+BKqoXQXBCYtH0r0c2e4TBwgZ0ER/30LehifAsazsspeQo2AZtL+hYI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776420776; c=relaxed/simple; bh=V5rNWvbJV8HY6Ar2nUAhh4fj7Pxw3e6oKH1XvFthwaY=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To:Cc: Content-Type; b=dCnL26OQIMu+qzopH+faNrQ9X1BhfwwymJzxLm8fvn4t6QO2G+rWqy2Ye7hI1/5gm+5O1gGJgoKm0+ooGTOs1VeYT/QBbZZj9AwlbgsP4cteu48jNGmxt5UwFIwDQROw6Wj9mfYoRgbXc1jVQhoKK5s0by+WmLRMwzAtId2/wyY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.210.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-7d7e9e02363so942541a34.2 for ; Fri, 17 Apr 2026 03:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776420773; x=1777025573; h=cc:to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uXW9PWZkGrdQlWzvHr+f6+SQPhB1AHombj76OTW9tDc=; b=UfLjTYbCuy5WTxdkkQCwZ40Mfa+zBiwyPEfolL5hCw87dQziCnXorJn93fa61QBWvP CNyocS9zS2zyFhuF3RccvlJNOGAHCaKBtek/8BOr36FGAMdyclHDjz0FhNLab1KaR3q4 yLzBf+9l/jTWYU+Zjr3AffihoNiLlUqZbDM2xl88s6RHOfvL04r56JjeVckM3RseLsGr qbJKHpnPXzufgZ2I1S3M8r+pwPjfdSDZM8dNsU+tM+tCnzkvHP8YrQMxJcpNSzZF9ASe jrBtezH2gn+fTSBo7NUBfym7C+6OboNcgLCrTvuJEEtrFnvg086P2U/NG1n3xAlC8+t1 zWPg== X-Forwarded-Encrypted: i=1; AFNElJ/5O8Y13TN85+98l/rOyXvHZ52qp4IdXWZdPZbtrZt/+bjeGr1snzPPwjuv+kkF0OlPBR0OXtpK9zqSVZU=@vger.kernel.org X-Gm-Message-State: AOJu0YzXb71ye576qLRz4jby/biHkp3wuJjGgfhrwIKldwhN+lLQT9cg wXYBZRABVjiX0Lcbx9IVYXEe565Qkcoo633m2nZlvFbtto8JhIbWXB5ZLE0U46S4O/HlLZ4ei2k dlPTMF/xb6I06DIBjtmsBKD9c4dYlsxcKGxDL/CW+qg05tMcLPmu9UhVr1as= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:6ad0:b0:68e:d9b7:7a29 with SMTP id 006d021491bc7-69462f5351emr1201673eaf.52.1776420772796; Fri, 17 Apr 2026 03:12:52 -0700 (PDT) Date: Fri, 17 Apr 2026 03:12:52 -0700 In-Reply-To: <20260417101250.2492247-1-tristmd@gmail.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69e207a4.050a0220.1de265.0014.GAE@google.com> Subject: Re: [PATCH] xfs: zero roundoff padding in xlog_sync to prevent From: syzbot To: tristmd@gmail.com Cc: tristmd@gmail.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" > From: Tristan Madani > > #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master This crash does not have a reproducer. I cannot test it. > > stale data exposure > > xlog_sync() rounds up the in-core log (iclog) write size to the log > stripe unit or sector size. The roundoff padding bytes between > iclog->ic_offset and the rounded-up boundary come from the iclog data > buffer, which is allocated once at mount time with kvzalloc but is > reused across log writes without re-zeroing. > > When an iclog is reused, the padding region may contain stale data > from a previous log write. xlog_pack_data() and xlog_cksum() then > process these stale bytes, which KMSAN flags as use of uninitialized > memory. While the stale data is overwritten on disk during log > recovery, the KMSAN report indicates a real information hygiene issue. > > Zero the roundoff padding bytes before calling xlog_pack_data() to > ensure deterministic log content regardless of prior iclog state. > > Reported-by: syzbot+97f2c05378c5d68dcb8c@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=97f2c05378c5d68dcb8c > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Cc: stable@vger.kernel.org > Signed-off-by: Tristan Madani > --- > fs/xfs/xfs_log.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c > index XXXXXXX..XXXXXXX 100644 > --- a/fs/xfs/xfs_log.c > +++ b/fs/xfs/xfs_log.c > @@ -1731,6 +1731,10 @@ xlog_sync( > xlog_grant_add_space(&log->l_write_head, roundoff); > } > > + /* Zero roundoff padding to avoid writing stale data to the log */ > + if (roundoff) > + memset(iclog->ic_datap + iclog->ic_offset, 0, roundoff); > + > /* put cycle number in every block */ > xlog_pack_data(log, iclog, roundoff); > -- > 2.43.0