[PATCH] fscrypt: Fix null pointer when defer i_crypt_info

[PATCH] fscrypt: Fix null pointer when defer i_crypt_info

[Jun Nie]

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@syzkaller.appspotmail.com
Signed-off-by: Jun Nie <jun.nie@linaro.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);
 
-- 
2.34.1

Re: [PATCH] fscrypt: Fix null pointer when defer i_crypt_info

[Eric Biggers]

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@syzkaller.appspotmail.com
> Signed-off-by: Jun Nie <jun.nie@linaro.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

Re: [PATCH] fscrypt: Fix null pointer when defer i_crypt_info

[Jun Nie]

Eric Biggers <ebiggers@kernel.org> 于2022年12月14日周三 02:54写道：
>
> 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.
> >
>
> 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

Thanks for the information! Do you know what's the plan/schedule of
back porting,
such as linux-5.15.y branch?

- Jun

Re: [PATCH] fscrypt: Fix null pointer when defer i_crypt_info

[Eric Biggers]

On Wed, Dec 14, 2022 at 09:33:41AM +0800, Jun Nie wrote:
> Eric Biggers <ebiggers@kernel.org> 于2022年12月14日周三 02:54写道：
> >
> > 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.
> > >
> >
> > 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
> 
> Thanks for the information! Do you know what's the plan/schedule of
> back porting,
> such as linux-5.15.y branch?
> 
> - Jun

The commit has 'Cc: stable@vger.kernel.org', and it is marked as fixing a commit
in 5.9.  So it will be backported to 5.10 LTS and later.  It will take a little
while for the stable maintainers to pick it up, though, since it just made it
upstream yesterday.

- Eric