[SRU][B/X][CVE-2018-10322][PATCH 0/1] xfs: enhance dinode verifier

Thadeu Lima de Souza Cascardo cascardo at canonical.com
Tue Sep 1 20:46:04 UTC 2020


On Tue, Sep 01, 2020 at 03:36:29PM -0400, William Breathitt Gray wrote:
> On Tue, Sep 01, 2020 at 03:03:27PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > On Tue, Sep 01, 2020 at 12:57:08PM -0400, William Breathitt Gray wrote:
> > > [Regression Potential]
> > > 
> > > The upstream fix (commit b42db0860e13067fcc7cbfba3966c9e652668bbc)
> > > expects the affected code in the xfs_inode_buf.c file, but the affected
> > > code is in xfs_inode_fork.c file for the Bionic and Xenial kernels. This
> > > is because there was a refactoring performed in commit
> > > 71493b839e294065ba63bd6f8d07263f3afee8c6 in order to reject bad inodes
> > > earlier and in a single place. It is possible that waiting unti later to
> > > reject these bad inodes could have a negative side effect.
> > 
> > How hard it is to backport 71493b839e294065ba63bd6f8d07263f3afee8c6 to Bionic
> > and Xenial? And are there any fixups for that commit that we would rather
> > include?
> > 
> > Cascardo.
> 
> There are seven commits between commit 71493b839e29 and b42db0860e13:
> 
> b42db0860e13 xfs: enhance dinode verifier
> fa4493f0d9b3 xfs: remove dead inode version setting code
> 6a96c5650568 xfs: don't accept inode buffers with suspicious unlinked chains
> 8bb82bc12a9e xfs: move inode extent size hint validation to libxfs
> 6edb181053f0 xfs: refactor inode buffer verifier error logging
> 20c59c71ae71 Merge tag 'xfs-4.16-merge-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
> 22431bf3dfbf xfs: refactor inode verifier corruption error printing
> f0e28280629e xfs: convert to new i_version API
> 71493b839e29 xfs: move inode fork verifiers to xfs_dinode_verify
> 
> Of these commits, only 71493b839e29 seems relevant to xfs_dinode_verify.
> Backporting this commit is trivial. Would you like me to resubmit this
> patchset with 71493b839e29 included?
> 
> William Breathitt Gray

Yeah, I think it works better. Any later fixes will be more easily
backportable, and we will have code that do not digress too much from upstream.

Thanks.
Cascardo.



More information about the kernel-team mailing list