linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: Edward Adam Davis <eadavis@qq.com>,
	syzbot+bba84aef3a26fb93deb9@syzkaller.appspotmail.com
Cc: linux-fsdevel@vger.kernel.org,
	jfs-discussion@lists.sourceforge.net,
	syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [Jfs-discussion] [PATCH] jfs: reserve the header and use freelist from second
Date: Wed, 10 Apr 2024 11:58:57 -0500	[thread overview]
Message-ID: <f4f7c644-b229-486b-973b-97c55dac334f@oracle.com> (raw)
In-Reply-To: <tencent_59925DB41938CFAC0DDEA5A40DB592425D07@qq.com>

On 4/10/24 2:05AM, Edward Adam Davis via Jfs-discussion wrote:
> [syzbot reported]
> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
> RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713
> ...
> [Analyze]
> When the pointer h has the same value as p, after writing name in UniStrncpy_to_le(),
> p->header.flag will be cleared.
> This will cause the previously true judgment "p->header.flag & BT-LEAF" to change
> to no after writing the name operation, this leads to entering an incorrect branch
> and accessing the uninitialized object ih when judging this condition for the
> second time.
> [Fix]
> When allocating slots from the freelist, we start from the second one to preserve
> the header of p from being incorrectly modified.

The freelist is simply corrupted. It should never be set to 0. We cannot 
assume that slot[1] is on the free list. Probably the best we can do is 
to add more sanity checking to the freelist value, and/or any slot's 
next & prev value. That could potentially involve a lot more checks. 
I've been accepting patches here and there for specific syzbot failures, 
but any comprehensive sanity checking of every data structure would be a 
huge effort.

What makes a fix a little more difficult is that dtInsertEntry returns 
void and it would be difficult to gracefully recover. One could change 
it to return an error and have all the callers check that. But I'm 
afraid, just using a valid slot number would only lead to further data 
corruption.

Thanks,
Shaggy

> 
> Reported-by: syzbot+bba84aef3a26fb93deb9@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>   fs/jfs/jfs_dtree.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
> index 031d8f570f58..deb2a5cc78d8 100644
> --- a/fs/jfs/jfs_dtree.c
> +++ b/fs/jfs/jfs_dtree.c
> @@ -3618,7 +3618,8 @@ static void dtInsertEntry(dtpage_t * p, int index, struct component_name * key,
>   	kname = key->name;
>   
>   	/* allocate a free slot */
> -	hsi = fsi = p->header.freelist;
> +	hsi = fsi = p->header.freelist = p->header.freelist == 0 ?
> +		1 : p->header.freelist;
>   	h = &p->slot[fsi];
>   	p->header.freelist = h->next;
>   	--p->header.freecnt;

  reply	other threads:[~2024-04-10 16:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-09  6:22 [syzbot] [jfs?] general protection fault in dtInsertEntry syzbot
2024-04-10  7:05 ` [PATCH] jfs: reserve the header and use freelist from second Edward Adam Davis
2024-04-10 16:58   ` Dave Kleikamp [this message]
2024-04-11 12:05     ` [PATCH V2] jfs: fix null ptr deref in dtInsertEntry Edward Adam Davis
2024-06-26 17:30       ` Dave Kleikamp

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=f4f7c644-b229-486b-973b-97c55dac334f@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=eadavis@qq.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+bba84aef3a26fb93deb9@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /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;
as well as URLs for NNTP newsgroup(s).