linux-ext4 - Re: [PATCH] ext4: Save and restore state flags in EXT4_IOC

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4FCC2A0F.40804@tao.ma>
Date:	Mon, 04 Jun 2012 11:22:55 +0800
From:	Tao Ma <tm@....ma>
To:	Ted Ts'o <tytso@....edu>
CC:	linux-ext4@...r.kernel.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH] ext4: Save and restore state flags in EXT4_IOC_SETFLAGS.

Hi Ted,
	Sorry for the delay.
On 06/01/2012 11:48 AM, Ted Ts'o wrote:
> On Fri, May 04, 2012 at 11:37:49PM +0800, Tao Ma wrote:
>> From: Tao Ma <boyu.mt@...bao.com>
>>
>> In commit 353eb83c we removes i_state_flags with 64-bit longs,
>> But in case we call EXT4_IOC_SETFLAGS, we fail to save the
>> high 32-bit state flags and only stores the low 32-bit back
>> to ei->i_flags. So the state flags are missing now in 64-bit
>> long architecture.
> 
> The problem with this approach is that we are still editing i_flags
> and then replacing it with the new value.  So we're vulnerable to
> races where some other process is modifies the i_state_flags between
> when we sample it using ext4_save_state_flags() and when we restore
> them.
> 
> This is a better way to fix the problem, and what I plan to commit
> into the ext4 tree:
> 
> commit 79906964a187c405db72a3abc60eb9b50d804fbc
> Author: Theodore Ts'o <tytso@....edu>
> Date:   Thu May 31 23:46:01 2012 -0400
> 
>     ext4: don't trash state flags in EXT4_IOC_SETFLAGS
>     
>     In commit 353eb83c we removed i_state_flags with 64-bit longs, But
>     when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
>     directly, which trashes the state flags which are stored in the high
>     32-bits of i_flags on 64-bit platforms.  So use the the
>     ext4_{set,clear}_inode_flags() functions which use atomic bit
>     manipulation functions instead.
>     
>     Reported-by: Tao Ma <boyu.mt@...bao.com>
>     Signed-off-by: "Theodore Ts'o" <tytso@....edu>
>     Cc: stable@...nel.org
> 
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index feba55a..8ad112a 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -38,7 +38,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  		handle_t *handle = NULL;
>  		int err, migrate = 0;
>  		struct ext4_iloc iloc;
> -		unsigned int oldflags;
> +		unsigned int oldflags, mask, i;
>  		unsigned int jflag;
>  
>  		if (!inode_owner_or_capable(inode))
> @@ -115,8 +115,14 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  		if (err)
>  			goto flags_err;
>  
> -		flags = flags & EXT4_FL_USER_MODIFIABLE;
> -		flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
> +		for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
> +			if (!(mask & EXT4_FL_USER_MODIFIABLE))
> +				continue;
> +			if (mask & flags)
> +				ext4_set_inode_flag(inode, i);
> +			else
> +				ext4_clear_inode_flag(inode, i);
> +		}
>  		ei->i_flags = flags;
You forget to remove this line and we can still get the problem.

I am busy with other stuff and when I got to it, it is already in linus'
tree. So I have sent out another patch to remove this line and after
that my test case passed. The patch subject is "[PATCH] ext4: Don't set
i_flags in EXT4_IOC_SETFLAGS."

Thanks
Tao
>  
>  		ext4_set_inode_flags(inode);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html