Linux EXT4 FS development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Deepanshu Kartikey" <kartikey406@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext4: add bounds check for e_value_offs in ext4_read_inline_data
Date: Fri, 18 Sep 2026 01:19:29 +0000	[thread overview]
Message-ID: <20260918011930.22A121F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260918010558.8210-1-kartikey406@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ext4: information leak due to unhandled error in ext4_read_inline_page()
- [Low] ext4: undefined macro ITAIL causes compilation failure
--

commit 61b118bf302b061ec089fd01a981cb9991fa3a62
Author: Deepanshu Kartikey <kartikey406@gmail.com>
ext4: add bounds check for e_value_offs in ext4_read_inline_data

This patch adds a bounds check to ext4_read_inline_data() to validate the
location of inline data xattr values against the actual bounds of the inode's
xattr area. If the value is out of bounds, it returns -EFSCORRUPTED to
prevent reading out-of-bounds memory.

Closes: https://syzkaller.appspot.com/bug?extid=085a394c92518a04fd09

> diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
> index caa51473207d7..7d5592030ec32 100644
> --- a/fs/ext4/inline.c
> +++ b/fs/ext4/inline.c

[ ... ]

> @@ -188,13 +190,21 @@ static int ext4_read_inline_data(struct inode *inode, void *buffer,
>  		goto out;
>  
>  	header = IHDR(inode, raw_inode);
> +	end = ITAIL(inode, raw_inode);

[Severity: Low]
Does this code compile? ITAIL() appears to be undefined in this context,
which would break the build.

>  	entry = (struct ext4_xattr_entry *)((void *)raw_inode +
>  					    EXT4_I(inode)->i_inline_off);
>  	len = min_t(unsigned int, len,
>  		    (unsigned int)le32_to_cpu(entry->e_value_size));
>  
> -	memcpy(buffer,
> -	       (void *)IFIRST(header) + le16_to_cpu(entry->e_value_offs), len);
> +	offset = le16_to_cpu(entry->e_value_offs);
> +	p = (void *)IFIRST(header) + offset;
> +
> +	if (unlikely(p + len > end)) {
> +		EXT4_ERROR_INODE(inode, "corrupt inline xattr entry");
> +		return -EFSCORRUPTED;

[Severity: High]
Does returning an error code here cause an information leak?

Looking at ext4_read_inline_page(), it calls this function but does not
check if the return value is negative before unconditionally zeroing the tail
and marking the page as up-to-date:

fs/ext4/inline.c:ext4_read_inline_page() {
    ...
    ret = ext4_read_inline_data(inode, kaddr, len, &iloc);
    flush_dcache_page(page);
    kunmap_atomic(kaddr);
    zero_user_segment(page, len, PAGE_SIZE);
    SetPageUptodate(page);
    ...
}

If this returns -EFSCORRUPTED, will the page be left with uninitialized
kernel memory that gets exposed to userspace?

> +	}
> +
> +	memcpy(buffer, p, len);
>  	cp_len += len;
>  
>  out:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918010558.8210-1-kartikey406@gmail.com?part=1

  reply	other threads:[~2026-09-18  1:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  1:05 [PATCH] ext4: add bounds check for e_value_offs in ext4_read_inline_data Deepanshu Kartikey
2026-09-18  1:19 ` sashiko-bot [this message]
2026-09-24 16:10 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260918011930.22A121F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kartikey406@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox