From: <gregkh@linuxfoundation.org>
To: jamie@nuviainc.com, dhowells@redhat.com, richard@nod.at,
stable@vger.kernel.org
Cc: <stable@vger.kernel.org>
Subject: FAILED: patch "[PATCH] jffs2: Fix NULL pointer dereference in rp_size fs option" failed to apply to 5.4-stable tree
Date: Mon, 28 Dec 2020 10:31:49 +0100 [thread overview]
Message-ID: <16091479096513@kroah.com> (raw)
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a61df3c413e49b0042f9caf774c58512d1cc71b7 Mon Sep 17 00:00:00 2001
From: Jamie Iles <jamie@nuviainc.com>
Date: Mon, 12 Oct 2020 14:12:04 +0100
Subject: [PATCH] jffs2: Fix NULL pointer dereference in rp_size fs option
parsing
syzkaller found the following JFFS2 splat:
Unable to handle kernel paging request at virtual address dfffa00000000001
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[dfffa00000000001] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] SMP
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 12745 Comm: syz-executor.5 Tainted: G S 5.9.0-rc8+ #98
Hardware name: linux,dummy-virt (DT)
pstate: 20400005 (nzCv daif +PAN -UAO BTYPE=--)
pc : jffs2_parse_param+0x138/0x308 fs/jffs2/super.c:206
lr : jffs2_parse_param+0x108/0x308 fs/jffs2/super.c:205
sp : ffff000022a57910
x29: ffff000022a57910 x28: 0000000000000000
x27: ffff000057634008 x26: 000000000000d800
x25: 000000000000d800 x24: ffff0000271a9000
x23: ffffa0001adb5dc0 x22: ffff000023fdcf00
x21: 1fffe0000454af2c x20: ffff000024cc9400
x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: ffffa000102dbdd0
x15: 0000000000000000 x14: ffffa000109e44bc
x13: ffffa00010a3a26c x12: ffff80000476e0b3
x11: 1fffe0000476e0b2 x10: ffff80000476e0b2
x9 : ffffa00010a3ad60 x8 : ffff000023b70593
x7 : 0000000000000003 x6 : 00000000f1f1f1f1
x5 : ffff000023fdcf00 x4 : 0000000000000002
x3 : ffffa00010000000 x2 : 0000000000000001
x1 : dfffa00000000000 x0 : 0000000000000008
Call trace:
jffs2_parse_param+0x138/0x308 fs/jffs2/super.c:206
vfs_parse_fs_param+0x234/0x4e8 fs/fs_context.c:117
vfs_parse_fs_string+0xe8/0x148 fs/fs_context.c:161
generic_parse_monolithic+0x17c/0x208 fs/fs_context.c:201
parse_monolithic_mount_data+0x7c/0xa8 fs/fs_context.c:649
do_new_mount fs/namespace.c:2871 [inline]
path_mount+0x548/0x1da8 fs/namespace.c:3192
do_mount+0x124/0x138 fs/namespace.c:3205
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount fs/namespace.c:3390 [inline]
__arm64_sys_mount+0x164/0x238 fs/namespace.c:3390
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common.constprop.0+0x15c/0x598 arch/arm64/kernel/syscall.c:149
do_el0_svc+0x60/0x150 arch/arm64/kernel/syscall.c:195
el0_svc+0x34/0xb0 arch/arm64/kernel/entry-common.c:226
el0_sync_handler+0xc8/0x5b4 arch/arm64/kernel/entry-common.c:236
el0_sync+0x15c/0x180 arch/arm64/kernel/entry.S:663
Code: d2d40001 f2fbffe1 91002260 d343fc02 (38e16841)
---[ end trace 4edf690313deda44 ]---
This is because since ec10a24f10c8, the option parsing happens before
fill_super and so the MTD device isn't associated with the filesystem.
Defer the size check until there is a valid association.
Fixes: ec10a24f10c8 ("vfs: Convert jffs2 to use the new mount API")
Cc: <stable@vger.kernel.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Jamie Iles <jamie@nuviainc.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index c523adaca79f..81ca58c10b72 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -202,12 +202,8 @@ static int jffs2_parse_param(struct fs_context *fc, struct fs_parameter *param)
case Opt_rp_size:
if (result.uint_32 > UINT_MAX / 1024)
return invalf(fc, "jffs2: rp_size unrepresentable");
- opt = result.uint_32 * 1024;
- if (opt > c->mtd->size)
- return invalf(fc, "jffs2: Too large reserve pool specified, max is %llu KB",
- c->mtd->size / 1024);
+ c->mount_opts.rp_size = result.uint_32 * 1024;
c->mount_opts.set_rp_size = true;
- c->mount_opts.rp_size = opt;
break;
default:
return -EINVAL;
@@ -269,6 +265,10 @@ static int jffs2_fill_super(struct super_block *sb, struct fs_context *fc)
c->mtd = sb->s_mtd;
c->os_priv = sb;
+ if (c->mount_opts.rp_size > c->mtd->size)
+ return invalf(fc, "jffs2: Too large reserve pool specified, max is %llu KB",
+ c->mtd->size / 1024);
+
/* Initialize JFFS2 superblock locks, the further initialization will
* be done later */
mutex_init(&c->alloc_sem);
reply other threads:[~2020-12-28 9:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=16091479096513@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dhowells@redhat.com \
--cc=jamie@nuviainc.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.