From: "Ernesto A. Fernández" <firstname.lastname@example.org>
To: Dan Carpenter <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Peilin Ye <firstname.lastname@example.org>
Subject: Re: [Linux-kernel-mentees] [PATCH] hfs, hfsplus: Fix NULL pointer dereference in hfs_find_init()
Date: Wed, 12 Aug 2020 17:24:20 -0300 [thread overview]
Message-ID: <20200812202420.GA5873@eaf> (raw)
On Wed, Aug 12, 2020 at 11:59:04AM +0300, Dan Carpenter wrote:
> Yeah, the patch doesn't work at all. I looked at one call tree and it
> hfs_mdb_get() tries to allocate HFS_SB(sb)->ext_tree.
> HFS_SB(sb)->ext_tree = hfs_btree_open(sb, HFS_EXT_CNID, hfs_ext_keycmp);
> hfs_btree_open() calls page = read_mapping_page(mapping, 0, NULL);
> read_mapping_page() calls mapping->a_ops->readpage() which leads to
> hfs_readpage() which leads to hfs_ext_read_extent() which calls
> res = hfs_find_init(HFS_SB(inode->i_sb)->ext_tree, &fd);
> So we need ->ext_tree to be non-NULL before we can set ->ext_tree to be
> non-NULL... :/
For HFS+, the first 8 extents for a file are kept inside its own fork data
structure, not in the extent tree. So, in normal operation, you don't need
to search the extent tree to find the first page of the extent tree itself.
The HFS layout is different, but it should work the same way.
Of course this sort of thing can still be triggered by crafted filesystems.
If that's what the reproducer is about, I think just returning an error is
reasonable. But these modules will never be safe against attacks such as
> I wonder how long this has been broken and if we should just delete the
> AFS file system.
> dan carpenter
Linux-kernel-mentees mailing list
next prev parent reply other threads:[~2020-08-12 20:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 6:55 [Linux-kernel-mentees] [PATCH] hfs, hfsplus: Fix NULL pointer dereference in hfs_find_init() Peilin Ye
2020-08-12 7:08 ` Greg Kroah-Hartman
2020-08-12 7:13 ` Peilin Ye
2020-08-12 8:18 ` Greg Kroah-Hartman
2020-08-12 16:33 ` Peilin Ye
2020-08-12 8:59 ` Dan Carpenter
2020-08-12 11:42 ` Big Budsupply
2020-08-12 17:23 ` Peilin Ye
2020-08-12 20:24 ` Ernesto A. Fernández [this message]
2020-08-12 20:34 ` Ernesto A. Fernández
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).