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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 9 Sep 2010 18:38:08 +0200
From:	Jan Kara <>
To:	Andreas Dilger <>
Cc:	Jan Kara <>,
	Masayoshi MIZUMA <>,
	Andrew Morton <>,
	linux-ext4 <>
Subject: Re: [PATCH] [RESEND] ext3: set i_extra_isize of 11th inode

On Fri 27-08-10 12:57:47, Andreas Dilger wrote:
> On 2010-08-27, at 07:58, Jan Kara wrote:
> >  first let me explain one thing: I definitely agree that the issue
> > spotted by Masayoshi MIZUMA is more serious than some possible problem
> > with ancient e2fsprogs. What I was discussing about is, whether we should
> > fix the issue with the original patch (removing the workaround from
> > ext3_iget) or with my patch (putting the same logic into ext3_new_inode so
> > that it does not create xattrs which ext3_iget will just ignore).
> I agree that this is a safe fix, but it will propagate the workaround far
> into the future instead of actually fixing it.
> >  The disadvantage of my fix is that xattrs for inos <= EXT3_FIRST_INO will
> > be always stored out of inode, the disadvantage of the original patch is
> > the remote possibility of problems with ancient e2fsprogs.
> I don't think there are realistic chances of problems with older
> filesystems running newer kernels.  I think the workaround that was
> suggested below is also totally safe - instead of silently erasing the
> xattr (as kernels do today), or returning an error with a bad
> i_extra_isize (as would happen with the originally proposed patch) it
> will "know" that this bad value on low-numbered inodes was caused by
> mke2fs and just reset it instead of returning the error.
  Sigh, sorry to bring this up again... I wanted to use the original patch
with the workaround you suggested but realized there's still a hole. The
new patched kernel will happily use extra inode space for xattrs for inode
11 but if you mount the filesystem with older kernel it will reset
i_extra_size to zero and thus you'll lose the stored xattrs.
  So to get out of this compatibility trap we'd have to accept xattrs in
the extended inode space but never store it there and after a sufficiently
long time, we could remove the workaround. But this seems not worth the
effort to me given we speak about a single inode and rather trivial
workaround in ext3_iget and ext3_new_inode.
  Any ideas Andreas?

Jan Kara <>
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists