From: Salvatore Bonaccorso <carnil@debian.org>
To: Vasiliy Kovalev <kovalev@altlinux.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-patches@linuxtesting.org, dutyrok@altlinux.org,
gerben@altlinux.org,
syzbot+5f3a973ed3dfb85a6683@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key
Date: Thu, 20 Mar 2025 20:30:15 +0100 [thread overview]
Message-ID: <Z9xsx-w4YCBuYjx5@eldamar.lan> (raw)
In-Reply-To: <20241019191303.24048-1-kovalev@altlinux.org>
Hi
On Sat, Oct 19, 2024 at 10:13:03PM +0300, Vasiliy Kovalev wrote:
> Syzbot reported an issue in hfs subsystem:
>
> BUG: KASAN: slab-out-of-bounds in memcpy_from_page include/linux/highmem.h:423 [inline]
> BUG: KASAN: slab-out-of-bounds in hfs_bnode_read fs/hfs/bnode.c:35 [inline]
> BUG: KASAN: slab-out-of-bounds in hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70
> Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102
>
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:377 [inline]
> print_report+0x169/0x550 mm/kasan/report.c:488
> kasan_report+0x143/0x180 mm/kasan/report.c:601
> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
> __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
> memcpy_from_page include/linux/highmem.h:423 [inline]
> hfs_bnode_read fs/hfs/bnode.c:35 [inline]
> hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70
> hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159
> hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118
> hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232
> vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257
> do_mkdirat+0x264/0x3a0 fs/namei.c:4280
> __do_sys_mkdir fs/namei.c:4300 [inline]
> __se_sys_mkdir fs/namei.c:4298 [inline]
> __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fbdd6057a99
>
> Add a check for key length in hfs_bnode_read_key to prevent
> out-of-bounds memory access. If the key length is invalid, the
> key buffer is cleared, improving stability and reliability.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+5f3a973ed3dfb85a6683@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=5f3a973ed3dfb85a6683
> Cc: stable@vger.kernel.org
> Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
> ---
> fs/hfs/bnode.c | 6 ++++++
> fs/hfsplus/bnode.c | 6 ++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
> index 6add6ebfef8967..cb823a8a6ba960 100644
> --- a/fs/hfs/bnode.c
> +++ b/fs/hfs/bnode.c
> @@ -67,6 +67,12 @@ void hfs_bnode_read_key(struct hfs_bnode *node, void *key, int off)
> else
> key_len = tree->max_key_len + 1;
>
> + if (key_len > sizeof(hfs_btree_key) || key_len < 1) {
> + memset(key, 0, sizeof(hfs_btree_key));
> + pr_err("hfs: Invalid key length: %d\n", key_len);
> + return;
> + }
> +
> hfs_bnode_read(node, key, off, key_len);
> }
>
> diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c
> index 87974d5e679156..079ea80534f7de 100644
> --- a/fs/hfsplus/bnode.c
> +++ b/fs/hfsplus/bnode.c
> @@ -67,6 +67,12 @@ void hfs_bnode_read_key(struct hfs_bnode *node, void *key, int off)
> else
> key_len = tree->max_key_len + 2;
>
> + if (key_len > sizeof(hfsplus_btree_key) || key_len < 1) {
> + memset(key, 0, sizeof(hfsplus_btree_key));
> + pr_err("hfsplus: Invalid key length: %d\n", key_len);
> + return;
> + }
> +
> hfs_bnode_read(node, key, off, key_len);
> }
>
> --
> 2.33.8
I do realize that the HFS filesystem is "Orphan". But in the light of
the disclosure in
https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/
is there still something which needs to be done here?
Does the above needs to be picked in mainline and then propagated to
the supported stable versions?
Regards,
Salvatore
next prev parent reply other threads:[~2025-03-20 19:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-19 19:13 [PATCH] hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key Vasiliy Kovalev
2025-03-20 19:30 ` Salvatore Bonaccorso [this message]
2025-03-24 16:14 ` Cengiz Can
2025-03-24 16:17 ` Greg KH
2025-03-24 18:43 ` Cengiz Can
2025-03-24 18:53 ` Greg KH
2025-04-06 16:07 ` Cengiz Can
2025-04-06 16:28 ` Greg KH
2025-04-07 10:59 ` Christian Brauner
2025-04-07 17:15 ` Christian Brauner
2025-04-07 17:29 ` Attila Szasz
2025-04-07 19:08 ` Darrick J. Wong
2025-04-08 10:11 ` Richard Weinberger
2025-04-08 14:50 ` Darrick J. Wong
2025-04-08 15:58 ` Richard Weinberger
2025-04-16 15:10 ` Eric Sandeen
2025-04-08 8:03 ` Greg KH
2025-04-08 12:00 ` Attila Szasz
2025-03-27 19:15 ` Attila Szasz
2025-04-07 17:25 ` Christian Brauner
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=Z9xsx-w4YCBuYjx5@eldamar.lan \
--to=carnil@debian.org \
--cc=dutyrok@altlinux.org \
--cc=gerben@altlinux.org \
--cc=kovalev@altlinux.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-patches@linuxtesting.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+5f3a973ed3dfb85a6683@syzkaller.appspotmail.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).