linux-kernel - Re: [syzbot] possible deadlock in dquot

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>] [day] [month] [year] [list]

Message-ID: <20210812135529.GD14675@quack2.suse.cz>
Date:   Thu, 12 Aug 2021 15:55:29 +0200
From:   Jan Kara <jack@...e.cz>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Jan Kara <jack@...e.cz>,
        syzbot <syzbot+3b6f9218b1301ddda3e2@...kaller.appspotmail.com>,
        dvyukov@...gle.com, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, syzkaller@...glegroups.com,
        tytso@....edu
Subject: Re: [syzbot] possible deadlock in dquot_commit

On Wed 11-08-21 12:12:32, Hillf Danton wrote:
> On Tue, 10 Aug 2021 11:21:42 +0200 Jan Kara wrote:
> >
> >I'm not quite sure what you are asking about but yes, dquot_acquire() grabs
> 
> It is hard to understand the rooms in mutex for two lock owners.
> 
> >dquot->dq_lock, then e.g. v2_write_dquot() acquires dqio_sem, then
> >ext4_map_blocks() acquires i_data_sem/2 (special lock subclass for quota
> >files).
> >
> >What is unexpected is the #0 trace where i_data_sem/2 is acquired
> >by ext4_map_blocks() called from ext4_write_begin(). That shows that
> >normal write(2) call was able to operate on quota file which is certainly
> >wrong.
> 
> The change below can test your theory.
> >
> >My patch closed one path how this could happen and I'm puzzled how
> >else this could happen. I'll try to reproduce the issue (I've already tried
> >but so far failed) as see if I can find out more.
> 
> Actually there is one check for quota file near 100 lines of code lower,
> and copy it to just before taking i_data_sem to avoid writing the file of
> wrong type.
> 
> Now only for thoughts.
> 
> +++ x/fs/ext4/inode.c
> @@ -616,6 +616,8 @@ found:
>  		if (!(flags & EXT4_GET_BLOCKS_CONVERT_UNWRITTEN))
>  			return retval;
>  
> +	if (ext4_is_quota_file(inode))
> +		return -EINVAL;
>  	/*
>  	 * Here we clear m_flags because after allocating an new extent,
>  	 * it will be set again.

This would be certainly wrong. ext4_map_blocks() is used for accessing and
allocating blocks for quota file. It is ext4_write_begin() that should not
be called for the quota file. I've run the reproducer here for couple of
hours but the problem didn't trigger for me. Strange.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR