--- /dev/null
+From e720e7d0e983bf05de80b231bccc39f1487f0f16 Mon Sep 17 00:00:00 2001
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Date: Mon, 29 Mar 2021 21:42:08 -0700
+Subject: mm: fix race by making init_zero_pfn() early_initcall
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+
+commit e720e7d0e983bf05de80b231bccc39f1487f0f16 upstream.
+
+There are code paths that rely on zero_pfn to be fully initialized
+before core_initcall. For example, wq_sysfs_init() is a core_initcall
+function that eventually results in a call to kernel_execve, which
+causes a page fault with a subsequent mmput. If zero_pfn is not
+initialized by then it may not get cleaned up properly and result in an
+error:
+
+ BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1
+
+Here is an analysis of the race as seen on a MIPS device. On this
+particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until
+initialized, at which point it becomes PFN 5120:
+
+ 1. wq_sysfs_init calls into kobject_uevent_env at core_initcall:
+ kobject_uevent_env+0x7e4/0x7ec
+ kset_register+0x68/0x88
+ bus_register+0xdc/0x34c
+ subsys_virtual_register+0x34/0x78
+ wq_sysfs_init+0x1c/0x4c
+ do_one_initcall+0x50/0x1a8
+ kernel_init_freeable+0x230/0x2c8
+ kernel_init+0x10/0x100
+ ret_from_kernel_thread+0x14/0x1c
+
+ 2. kobject_uevent_env() calls call_usermodehelper_exec() which executes
+ kernel_execve asynchronously.
+
+ 3. Memory allocations in kernel_execve cause a page fault, bumping the
+ MM reference counter:
+ add_mm_counter_fast+0xb4/0xc0
+ handle_mm_fault+0x6e4/0xea0
+ __get_user_pages.part.78+0x190/0x37c
+ __get_user_pages_remote+0x128/0x360
+ get_arg_page+0x34/0xa0
+ copy_string_kernel+0x194/0x2a4
+ kernel_execve+0x11c/0x298
+ call_usermodehelper_exec_async+0x114/0x194
+
+ 4. In case zero_pfn has not been initialized yet, zap_pte_range does
+ not decrement the MM_ANONPAGES RSS counter and the BUG message is
+ triggered shortly afterwards when __mmdrop checks the ref counters:
+ __mmdrop+0x98/0x1d0
+ free_bprm+0x44/0x118
+ kernel_execve+0x160/0x1d8
+ call_usermodehelper_exec_async+0x114/0x194
+ ret_from_kernel_thread+0x14/0x1c
+
+To avoid races such as described above, initialize init_zero_pfn at
+early_initcall level. Depending on the architecture, ZERO_PAGE is
+either constant or gets initialized even earlier, at paging_init, so
+there is no issue with initializing zero_pfn earlier.
+
+Link: https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niAXOpqEbt7w@mail.gmail.com
+Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: stable@vger.kernel.org
+Tested-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -129,7 +129,7 @@ static int __init init_zero_pfn(void)
+ zero_pfn = page_to_pfn(ZERO_PAGE(0));
+ return 0;
+ }
+-core_initcall(init_zero_pfn);
++early_initcall(init_zero_pfn);
+
+
+ #if defined(SPLIT_RSS_COUNTING)
--- /dev/null
+From 5e46d1b78a03d52306f21f77a4e4a144b6d31486 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Date: Sun, 21 Mar 2021 23:37:49 +0900
+Subject: reiserfs: update reiserfs_xattrs_initialized() condition
+
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+
+commit 5e46d1b78a03d52306f21f77a4e4a144b6d31486 upstream.
+
+syzbot is reporting NULL pointer dereference at reiserfs_security_init()
+[1], for commit ab17c4f02156c4f7 ("reiserfs: fixup xattr_root caching")
+is assuming that REISERFS_SB(s)->xattr_root != NULL in
+reiserfs_xattr_jcreate_nblocks() despite that commit made
+REISERFS_SB(sb)->priv_root != NULL && REISERFS_SB(s)->xattr_root == NULL
+case possible.
+
+I guess that commit 6cb4aff0a77cc0e6 ("reiserfs: fix oops while creating
+privroot with selinux enabled") wanted to check xattr_root != NULL
+before reiserfs_xattr_jcreate_nblocks(), for the changelog is talking
+about the xattr root.
+
+ The issue is that while creating the privroot during mount
+ reiserfs_security_init calls reiserfs_xattr_jcreate_nblocks which
+ dereferences the xattr root. The xattr root doesn't exist, so we get
+ an oops.
+
+Therefore, update reiserfs_xattrs_initialized() to check both the
+privroot and the xattr root.
+
+Link: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde # [1]
+Reported-and-tested-by: syzbot <syzbot+690cb1e51970435f9775@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Fixes: 6cb4aff0a77c ("reiserfs: fix oops while creating privroot with selinux enabled")
+Acked-by: Jeff Mahoney <jeffm@suse.com>
+Acked-by: Jan Kara <jack@suse.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/reiserfs/xattr.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/reiserfs/xattr.h
++++ b/fs/reiserfs/xattr.h
+@@ -42,7 +42,7 @@ void reiserfs_security_free(struct reise
+
+ static inline int reiserfs_xattrs_initialized(struct super_block *sb)
+ {
+- return REISERFS_SB(sb)->priv_root != NULL;
++ return REISERFS_SB(sb)->priv_root && REISERFS_SB(sb)->xattr_root;
+ }
+
+ #define xattr_size(size) ((size) + sizeof(struct reiserfs_xattr_header))