linux-kernel - Re: [PATCH] xfs_logprint: Fix super block buffer interpretation issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZwxOrVCJ/+2GoGjg@dread.disaster.area>
Date: Mon, 14 Oct 2024 09:50:21 +1100
From: Dave Chinner <david@...morbit.com>
To: Chi Zhiling <chizhiling@....com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, cem@...nel.org,
	linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	chizhiling <chizhiling@...inos.cn>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] xfs_logprint: Fix super block buffer interpretation issue

On Sun, Oct 13, 2024 at 12:00:22PM +0800, Chi Zhiling wrote:
> On 2024/10/13 06:10, Dave Chinner wrote:
> > On Fri, Oct 11, 2024 at 11:54:08AM +0800, Chi Zhiling wrote:
> > > On 2024/10/11 11:24, Darrick J. Wong wrote:
> > > > On Fri, Oct 11, 2024 at 11:08:10AM +0800, Chi Zhiling wrote:
> > > > > From: chizhiling<chizhiling@...inos.cn>
> > > > > 
> > > > > When using xfs_logprint to interpret the buffer of the super block, the
> > > > > icount will always be 6360863066640355328 (0x5846534200001000). This is
> > > > > because the offset of icount is incorrect, causing xfs_logprint to
> > > > > misinterpret the MAGIC number as icount.
> > > > > This patch fixes the offset value of the SB counters in xfs_logprint.
> > > > > 
> > > > > Before this patch:
> > > > > icount: 6360863066640355328  ifree: 5242880  fdblks: 0  frext: 0
> > > > > 
> > > > > After this patch:
> > > > > icount: 10240  ifree: 4906  fdblks: 37  frext: 0
> > > > > 
> > > > > Signed-off-by: chizhiling<chizhiling@...inos.cn>
> > > > > ---
> > > > >    logprint/log_misc.c | 8 ++++----
> > > > >    1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/logprint/log_misc.c b/logprint/log_misc.c
> > > > > index 8e86ac34..21da5b8b 100644
> > > > > --- a/logprint/log_misc.c
> > > > > +++ b/logprint/log_misc.c
> > > > > @@ -288,13 +288,13 @@ xlog_print_trans_buffer(char **ptr, int len, int *i, int num_ops)
> > > > >    			/*
> > > > >    			 * memmove because *ptr may not be 8-byte aligned
> >                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > This is important. I'll come back to it.
> > 
> > > > >    			 */
> > > > > -			memmove(&a, *ptr, sizeof(__be64));
> > > > > -			memmove(&b, *ptr+8, sizeof(__be64));
> > > > How did this ever work??  This even looks wrong in "Release_1.0.0".
> > > > 
> > > Yes, I was surprised when I find this issue
> > I"ve never cared about these values when doing diagnosis because
> > lazy-count means they aren't guaranteed to be correct except at
> > unmount. At which point, the correct values are generally found
> > in the superblock. IOWs, the values are largely meaningless whether
> > they are correct or not, so nobody has really cared enough about
> > this to bother fixing it...
> 
> Because I got a log which shows that the fdblocks was (-8),   it caused
> the filesystem to fail mounting again. 'SB summary counter sanity check failed'

What kernel? Because AFAIK, that was fixed in commit 58f880711f2b
("xfs: make sure sb_fdblocks is non-negative") in 6.10...

-Dave.
-- 
Dave Chinner
david@...morbit.com