linux-kernel - Re: [PATCH] fscrypt: Fix null pointer when defer i_crypt

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

Message-ID: <Y5jKfdDrJkdKtEbC@sol.localdomain>
Date:   Tue, 13 Dec 2022 10:54:53 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Jun Nie <jun.nie@...aro.org>
Cc:     tytso@....edu, jaegeuk@...nel.org, linux-fscrypt@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fscrypt: Fix null pointer when defer i_crypt_info

On Tue, Dec 13, 2022 at 04:11:03PM +0800, Jun Nie wrote:
> syzbot report below bug[1]. Fix it with checking null pointer before
> deferring i_crypt_info.
> 
> [1]
> general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
> CPU: 3 PID: 456 Comm: repro Not tainted 6.1.0+gc0daf896 #169
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:fscrypt_limit_io_blocks+0xfa/0x2c0
> Call Trace:
>  <TASK>
>  ext4_iomap_begin+0x6c5/0x7e0
>  ? asym_cpu_capacity_scan+0x6b0/0x6b0
>  ? ext4_iomap_begin_report+0x6b0/0x6b0
>  ? __sanitizer_cov_trace_const_cmp1+0x1a/0x20
>  ? ext4_commit_super+0x3c1/0x560
>  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>  ? ext4_handle_error+0x3bf/0x6b0
>  ? ext4_iomap_begin_report+0x6b0/0x6b0
>  iomap_iter+0x538/0xc80
>  iomap_bmap+0x1ed/0x2d0
>  ? iomap_to_fiemap+0x220/0x220
>  ? rwsem_down_read_slowpath+0xc00/0xc00
>  ? __ext4_iget+0x19c/0x4370
>  ext4_bmap+0x288/0x470
>  ? mpage_prepare_extent_to_map+0xd80/0xd80
>  bmap+0xb1/0x120
>  jbd2_journal_init_inode+0x7d/0x3f0
>  ? up_write+0x6c/0xb0
>  ? jbd2_journal_init_dev+0x130/0x130
>  ? register_shrinker+0x33/0x160
>  ext4_fill_super+0xa467/0xc650
>  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
>  ? ext4_reconfigure+0x2ad0/0x2ad0
>  ? snprintf+0xbb/0xf0
>  ? vsprintf+0x40/0x40
>  ? up_write+0x6c/0xb0
>  ? __sanitizer_cov_trace_cmp4+0x16/0x20
>  ? set_blocksize+0x2f0/0x380
>  get_tree_bdev+0x438/0x740
>  ? get_tree_bdev+0x438/0x740
>  ? ext4_reconfigure+0x2ad0/0x2ad0
>  ext4_get_tree+0x1d/0x30
>  vfs_get_tree+0x88/0x2e0
>  path_mount+0x6ca/0x1ec0
>  ? putname+0x110/0x150
>  ? finish_automount+0x790/0x790
>  ? putname+0x115/0x150
>  __x64_sys_mount+0x2aa/0x340
>  ? copy_mnt_ns+0xab0/0xab0
>  ? __sanitizer_cov_trace_cmp4+0x16/0x20
>  ? exit_to_user_mode_prepare+0x40/0x120
>  do_syscall_64+0x35/0x80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> Fixes: 5fee36095cda ("fscrypt: add inline encryption support")
> Reported-by: syzbot+ba9dac45bc76c490b7c3@...kaller.appspotmail.com
> Signed-off-by: Jun Nie <jun.nie@...aro.org>
> ---
>  fs/crypto/inline_crypt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c
> index cea8b14007e6..fec859e83774 100644
> --- a/fs/crypto/inline_crypt.c
> +++ b/fs/crypto/inline_crypt.c
> @@ -232,7 +232,7 @@ void fscrypt_destroy_inline_crypt_key(struct super_block *sb,
>  
>  bool __fscrypt_inode_uses_inline_crypto(const struct inode *inode)
>  {
> -	return inode->i_crypt_info->ci_inlinecrypt;
> +	return inode->i_crypt_info && inode->i_crypt_info->ci_inlinecrypt;
>  }
>  EXPORT_SYMBOL_GPL(__fscrypt_inode_uses_inline_crypto);

Thanks, but this has already been fixed upstream by commit 105c78e12468
("ext4: don't allow journal inode to have encrypt flag").

Also, I don't think adding a NULL check to __fscrypt_inode_uses_inline_crypto()
is a good idea because it is only meant to be called when the inode's encryption
key has already been set up.  Instead of making the function return a
potentially-incorrect result, it was better to address the root cause of why it
was being called at an inappropriate time in the first place.

- Eric