[PATCH 0/2] add and use vma_assert_stabilised() helper

[PATCH 0/2] add and use vma_assert_stabilised() helper

[Lorenzo Stoakes]

Sometimes we wish to assert that a VMA is stable, that is - the VMA cannot
be changed underneath us. This will be the case if EITHER the VMA lock or
the mmap lock is held.

We already open-code this in two places - anon_vma_name() in mm/madvise.c
and vma_flag_set_atomic() in include/linux/mm.h.

This series adds a number of pre-requisite predicates and adds
vma_assert_stablisied() which can be used in these callsites instead.

However the asserts implemented there subtly wrong - if CONFIG_PER_VMA_LOCK
is not implemented and the mmap lock is not held, then we don't actually
assert anything.

Since this is an assert that only fires when CONFIG_DEBUG_VM is set and the
test bots will largely be running with CONFIG_PER_VMA_LOCK set, this is
likely in practice not a real-world issue.

In any case, this series additionally fixes this issue.

As part of this change we also reduce duplication of code in VMA lock
asserts.

This change also lays the foundation for future series to add this assert
in further appropriate places to account for us now living in a world where
a VMA may be stablised by either lock.

Lorenzo Stoakes (2):
  mm/vma: add vma_is_*_locked() helpers
  mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers

 include/linux/mm.h        |  4 +--
 include/linux/mmap_lock.h | 55 +++++++++++++++++++++++++++++++++------
 mm/madvise.c              |  4 +--
 3 files changed, 49 insertions(+), 14 deletions(-)

--
2.52.0

[PATCH 1/2] mm/vma: add vma_is_*_locked() helpers

[Lorenzo Stoakes]

Add vma_is_read_locked(), vma_is_write_locked() and vma_is_locked() helpers
and utilise them in vma_assert_locked() and vma_assert_write_locked().

These functions will intentionally not be defined if CONFIG_PER_VMA_LOCK is
not set, as they would not make any sense in a context where VMA locks do
not exist.

This lays the groundwork for a subsequent change that allows for asserting
that either the mmap lock or VMA lock is held.

Suggested-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 include/linux/mmap_lock.h | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index b50416fbba20..cd51e0a43c76 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -236,19 +236,31 @@ int vma_start_write_killable(struct vm_area_struct *vma)
 	return __vma_start_write(vma, mm_lock_seq, TASK_KILLABLE);
 }
 
-static inline void vma_assert_write_locked(struct vm_area_struct *vma)
+static inline bool vma_is_read_locked(struct vm_area_struct *vma)
+{
+	return refcount_read(&vma->vm_refcnt) > 1;
+}
+
+static inline bool vma_is_write_locked(struct vm_area_struct *vma)
 {
 	unsigned int mm_lock_seq;
 
-	VM_BUG_ON_VMA(!__is_vma_write_locked(vma, &mm_lock_seq), vma);
+	return __is_vma_write_locked(vma, &mm_lock_seq);
 }
 
-static inline void vma_assert_locked(struct vm_area_struct *vma)
+static inline bool vma_is_locked(struct vm_area_struct *vma)
 {
-	unsigned int mm_lock_seq;
+	return vma_is_read_locked(vma) || vma_is_write_locked(vma);
+}
 
-	VM_BUG_ON_VMA(refcount_read(&vma->vm_refcnt) <= 1 &&
-		      !__is_vma_write_locked(vma, &mm_lock_seq), vma);
+static inline void vma_assert_write_locked(struct vm_area_struct *vma)
+{
+	VM_BUG_ON_VMA(!vma_is_write_locked(vma), vma);
+}
+
+static inline void vma_assert_locked(struct vm_area_struct *vma)
+{
+	VM_BUG_ON_VMA(!vma_is_locked(vma), vma);
 }
 
 static inline bool vma_is_attached(struct vm_area_struct *vma)
-- 
2.52.0

[PATCH 2/2] mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers

[Lorenzo Stoakes]

Sometimes we wish to assert that a VMA is stable, that is - the VMA cannot
be changed underneath us. This will be the case if EITHER the VMA lock or
the mmap lock is held.

In order to be able to do so this patch adds an mmap_is_locked() helper as
well as a vma_is_stabilised() predicate.

We specify this differently based on whether CONFIG_PER_VMA_LOCK is
specified - if it is then naturally we check both whether a VMA lock is
held or an mmap lock held, otherwise we need only check the mmap lock.

Note that we only trigger the assert is CONFIG_DEBUG_VM is set, as having
this lock unset would indicate a programmatic error, so a release kernel
runtime assert doesn't make much sense.

There are a couple places in the kernel where we already do this check -
the anon_vma_name() helper in mm/madvise.c and vma_flag_set_atomic() in
include/linux/mm.h, which we update to use vma_assert_stabilised().

These were in fact implemented incorrectly - if neither the mmap lock nor
the VMA lock were held, these asserts did not fire.

However since these asserts are debug-only, and a large number of test
configurations will have CONFIG_PER_VMA_LOCK set, it has likely had no
real-world impact.

This change corrects this mistake at any rate.

As part of this change we also move mmap_lock_is_contended() up in
include/linux/mmap_lock.h so we group predicates based on mmap lock state
together.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 include/linux/mm.h        |  4 +---
 include/linux/mmap_lock.h | 31 +++++++++++++++++++++++++++++--
 mm/madvise.c              |  4 +---
 3 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 44a2a9c0a92f..8707059f4d37 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1008,9 +1008,7 @@ static inline void vma_flag_set_atomic(struct vm_area_struct *vma,
 {
 	unsigned long *bitmap = ACCESS_PRIVATE(&vma->flags, __vma_flags);
 
-	/* mmap read lock/VMA read lock must be held. */
-	if (!rwsem_is_locked(&vma->vm_mm->mmap_lock))
-		vma_assert_locked(vma);
+	vma_assert_stabilised(vma);
 
 	if (__vma_flag_atomic_valid(vma, bit))
 		set_bit((__force int)bit, bitmap);
diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index cd51e0a43c76..d87a07608295 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -66,6 +66,16 @@ static inline void __mmap_lock_trace_released(struct mm_struct *mm, bool write)
 
 #endif /* CONFIG_TRACING */
 
+static inline bool mmap_lock_is_contended(struct mm_struct *mm)
+{
+	return rwsem_is_contended(&mm->mmap_lock);
+}
+
+static inline bool mmap_is_locked(struct mm_struct *mm)
+{
+	return rwsem_is_locked(&mm->mmap_lock);
+}
+
 static inline void mmap_assert_locked(const struct mm_struct *mm)
 {
 	rwsem_assert_held(&mm->mmap_lock);
@@ -253,6 +263,11 @@ static inline bool vma_is_locked(struct vm_area_struct *vma)
 	return vma_is_read_locked(vma) || vma_is_write_locked(vma);
 }
 
+static inline bool vma_is_stabilised(struct vm_area_struct *vma)
+{
+	return vma_is_locked(vma) || mmap_is_locked(vma->vm_mm);
+}
+
 static inline void vma_assert_write_locked(struct vm_area_struct *vma)
 {
 	VM_BUG_ON_VMA(!vma_is_write_locked(vma), vma);
@@ -339,6 +354,11 @@ static inline struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
 	return NULL;
 }
 
+static inline bool vma_is_stabilised(struct vm_area_struct *vma)
+{
+	return mmap_is_locked(vma->vm_mm);
+}
+
 static inline void vma_assert_locked(struct vm_area_struct *vma)
 {
 	mmap_assert_locked(vma->vm_mm);
@@ -444,9 +464,16 @@ static inline void mmap_read_unlock_non_owner(struct mm_struct *mm)
 	up_read_non_owner(&mm->mmap_lock);
 }
 
-static inline int mmap_lock_is_contended(struct mm_struct *mm)
+/**
+ * vma_assert_stabilised() - assert that this VMA cannot be changed from
+ * underneath us either by having a VMA or mmap lock held.
+ * @vma: The VMA whose stability we wish to assess.
+ *
+ * Note that this will only trigger an assert if CONFIG_DEBUG_VM is set.
+ */
+static inline void vma_assert_stabilised(struct vm_area_struct *vma)
 {
-	return rwsem_is_contended(&mm->mmap_lock);
+	VM_BUG_ON_VMA(vma_is_stabilised(vma), vma);
 }
 
 #endif /* _LINUX_MMAP_LOCK_H */
diff --git a/mm/madvise.c b/mm/madvise.c
index 4bf4c8c38fd3..1f3040688f04 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -109,9 +109,7 @@ void anon_vma_name_free(struct kref *kref)
 
 struct anon_vma_name *anon_vma_name(struct vm_area_struct *vma)
 {
-	if (!rwsem_is_locked(&vma->vm_mm->mmap_lock))
-		vma_assert_locked(vma);
-
+	vma_assert_stabilised(vma);
 	return vma->anon_name;
 }
 
-- 
2.52.0

Re: [PATCH 2/2] mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers

[Lorenzo Stoakes]

On Fri, Jan 16, 2026 at 10:27:48AM +0000, Lorenzo Stoakes wrote:
[snip]
> diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> index cd51e0a43c76..d87a07608295 100644
> --- a/include/linux/mmap_lock.h
> +++ b/include/linux/mmap_lock.h
[snip]
> +/**
> + * vma_assert_stabilised() - assert that this VMA cannot be changed from
> + * underneath us either by having a VMA or mmap lock held.
> + * @vma: The VMA whose stability we wish to assess.
> + *
> + * Note that this will only trigger an assert if CONFIG_DEBUG_VM is set.
> + */
> +static inline void vma_assert_stabilised(struct vm_area_struct *vma)
>  {
> -	return rwsem_is_contended(&mm->mmap_lock);
> +	VM_BUG_ON_VMA(vma_is_stabilised(vma), vma);

OK not had enough coffee this morning :))

Obviously should be !vma_is_stabilised(vma).

Andrew - could you apply the fix-patch below or just fix up my mistake
inline?  Thanks!

Cheers, Lorenzo

From c95bba4f23981584b105e0e8c1d3ce763cc619e0 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Fri, 16 Jan 2026 10:30:11 +0000
Subject: [PATCH] fix

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 include/linux/mmap_lock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index d87a07608295..cb18bfa3ae27 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -473,7 +473,7 @@ static inline void mmap_read_unlock_non_owner(struct mm_struct *mm)
  */
 static inline void vma_assert_stabilised(struct vm_area_struct *vma)
 {
-	VM_BUG_ON_VMA(vma_is_stabilised(vma), vma);
+	VM_BUG_ON_VMA(!vma_is_stabilised(vma), vma);
 }

 #endif /* _LINUX_MMAP_LOCK_H */
--
2.52.0

Re: [PATCH 0/2] add and use vma_assert_stabilised() helper

[Lorenzo Stoakes]

OK sorry to do the extremely annoying pattern of 'immediate resend' but... :)

I realised there's another silly issue here, I will have some caffeine, fix
up, and do a resend.

All - please disregard this series :>))

Cheers, Lorenzo


On Fri, Jan 16, 2026 at 10:27:46AM +0000, Lorenzo Stoakes wrote:
> Sometimes we wish to assert that a VMA is stable, that is - the VMA cannot
> be changed underneath us. This will be the case if EITHER the VMA lock or
> the mmap lock is held.
>
> We already open-code this in two places - anon_vma_name() in mm/madvise.c
> and vma_flag_set_atomic() in include/linux/mm.h.
>
> This series adds a number of pre-requisite predicates and adds
> vma_assert_stablisied() which can be used in these callsites instead.
>
> However the asserts implemented there subtly wrong - if CONFIG_PER_VMA_LOCK
> is not implemented and the mmap lock is not held, then we don't actually
> assert anything.
>
> Since this is an assert that only fires when CONFIG_DEBUG_VM is set and the
> test bots will largely be running with CONFIG_PER_VMA_LOCK set, this is
> likely in practice not a real-world issue.
>
> In any case, this series additionally fixes this issue.
>
> As part of this change we also reduce duplication of code in VMA lock
> asserts.
>
> This change also lays the foundation for future series to add this assert
> in further appropriate places to account for us now living in a world where
> a VMA may be stablised by either lock.
>
> Lorenzo Stoakes (2):
>   mm/vma: add vma_is_*_locked() helpers
>   mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers
>
>  include/linux/mm.h        |  4 +--
>  include/linux/mmap_lock.h | 55 +++++++++++++++++++++++++++++++++------
>  mm/madvise.c              |  4 +--
>  3 files changed, 49 insertions(+), 14 deletions(-)
>
> --
> 2.52.0

[syzbot ci] Re: add and use vma_assert_stabilised() helper

[syzbot ci]

syzbot ci has tested the following series

[v1] add and use vma_assert_stabilised() helper
https://lore.kernel.org/all/cover.1768558900.git.lorenzo.stoakes@oracle.com
* [PATCH 1/2] mm/vma: add vma_is_*_locked() helpers
* [PATCH 2/2] mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers

and found the following issue:
kernel BUG in anon_vma_name

Full report is available here:
https://ci.syzbot.org/series/a3867085-bae4-4416-9704-3b23ef9c6006

***

kernel BUG in anon_vma_name

tree:      mm-new
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base:      eeb33083cc4749bdb61582eaeb5c200702607703
arch:      amd64
compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config:    https://ci.syzbot.org/builds/2e5b4d7e-a1a9-48c8-ae3b-654d3ac32e5c/config

Loaded X.509 cert 'Build time autogenerated kernel key: 65176d093d4baf94ab1e788ee9f46804766f83ba'
ima: Allocated hash algorithm: sha256
ima: No architecture policies found
evm: Initialising EVM extended attributes:
evm: security.selinux (disabled)
evm: security.SMACK64 (disabled)
evm: security.SMACK64EXEC (disabled)
evm: security.SMACK64TRANSMUTE (disabled)
evm: security.SMACK64MMAP (disabled)
evm: security.apparmor
evm: security.ima
evm: security.capability
evm: HMAC attrs: 0x1
PM:   Magic number: 10:472:582
tty ptyc0: hash matches
netconsole: network logging started
gtp: GTP module loaded (pdp ctx size 128 bytes)
rdma_rxe: loaded
cfg80211: Loading compiled-in X.509 certificates for regulatory database
Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
clk: Disabling unused clocks
ALSA device list:
  #0: Dummy 1
  #1: Loopback 1
  #2: Virtual MIDI Card 1
check access for rdinit=/init failed: -2, ignoring
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT4-fs (sda1): mounted filesystem b4773fba-1738-4da0-8a90-0fe043d0a496 ro with ordered data mode. Quota mode: none.
VFS: Mounted root (ext4 filesystem) readonly on device 8:1.
devtmpfs: mounted
Freeing unused kernel image (initmem) memory: 26044K
Write protecting the kernel read-only data: 212992k
Freeing unused kernel image (text/rodata gap) memory: 388K
Freeing unused kernel image (rodata/data gap) memory: 1776K
x86/mm: Checked W+X mappings: passed, no W+X pages found.
x86/mm: Checking user space page tables
x86/mm: Checked W+X mappings: passed, no W+X pages found.
Failed to set sysctl parameter 'max_rcu_stall_to_panic=1': parameter not found
Run /sbin/init as init process
vma ffff888175272d80 start 00007fffffffe000 end 00007ffffffff000 mm ffff888100079880
prot 8000000000000025 anon_vma ffff888110bf8000 vm_ops 0000000000000000
pgoff 7fffffffe file 0000000000000000 private_data 0000000000000000
refcnt 1
flags: 0x8118173(read|write|mayread|maywrite|mayexec|growsdown|seqread|randread|account|softdirty)
------------[ cut here ]------------
kernel BUG at ./include/linux/mmap_lock.h:476!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 1 Comm: init Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:anon_vma_name+0x253/0x260
Code: ff 4c 89 ff e8 8e 7d 0a 00 e9 e9 fe ff ff e8 34 db a2 ff eb 0c e8 2d db a2 ff eb 05 e8 26 db a2 ff 48 89 df e8 6e 77 08 ff 90 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
RSP: 0000:ffffc90000067550 EFLAGS: 00010286
RAX: 000000000000014c RBX: ffff888175272d80 RCX: 37717524f4bb9000
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1c3ae40 R12: dffffc0000000000
R13: dffffc0000000000 R14: 0000000000000001 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff88818e405000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 0000000110c5a000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 vma_modify_flags+0x203/0x330
 mprotect_fixup+0x46a/0xa50
 setup_arg_pages+0x565/0xae0
 load_elf_binary+0xc5e/0x2980
 bprm_execve+0x93d/0x1410
 kernel_execve+0x8ef/0x9e0
 try_to_run_init_process+0x13/0x60
 kernel_init+0xad/0x1d0
 ret_from_fork+0x51b/0xa40
 ret_from_fork_asm+0x1a/0x30
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:anon_vma_name+0x253/0x260
Code: ff 4c 89 ff e8 8e 7d 0a 00 e9 e9 fe ff ff e8 34 db a2 ff eb 0c e8 2d db a2 ff eb 05 e8 26 db a2 ff 48 89 df e8 6e 77 08 ff 90 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
RSP: 0000:ffffc90000067550 EFLAGS: 00010286
RAX: 000000000000014c RBX: ffff888175272d80 RCX: 37717524f4bb9000
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffffbfff1c3ae40 R12: dffffc0000000000
R13: dffffc0000000000 R14: 0000000000000001 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff88818e405000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 0000000110c5a000 CR4: 00000000000006f0


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

Re: [syzbot ci] Re: add and use vma_assert_stabilised() helper

[Lorenzo Stoakes]

Please ignore, this whole series has been resent at [0].

Cheers, Lorenzo

[0]: https://lore.kernel.org/linux-mm/cover.1768569863.git.lorenzo.stoakes@oracle.com/

On Fri, Jan 16, 2026 at 05:51:01AM -0800, syzbot ci wrote:
> syzbot ci has tested the following series
>
> [v1] add and use vma_assert_stabilised() helper
> https://lore.kernel.org/all/cover.1768558900.git.lorenzo.stoakes@oracle.com
> * [PATCH 1/2] mm/vma: add vma_is_*_locked() helpers
> * [PATCH 2/2] mm: add + use vma_is_stabilised(), vma_assert_stabilised() helpers
>
> and found the following issue:
> kernel BUG in anon_vma_name
>
> Full report is available here:
> https://ci.syzbot.org/series/a3867085-bae4-4416-9704-3b23ef9c6006
>
> ***
>
> kernel BUG in anon_vma_name
>
> tree:      mm-new
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
> base:      eeb33083cc4749bdb61582eaeb5c200702607703
> arch:      amd64
> compiler:  Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
> config:    https://ci.syzbot.org/builds/2e5b4d7e-a1a9-48c8-ae3b-654d3ac32e5c/config
>
> Loaded X.509 cert 'Build time autogenerated kernel key: 65176d093d4baf94ab1e788ee9f46804766f83ba'
> ima: Allocated hash algorithm: sha256
> ima: No architecture policies found
> evm: Initialising EVM extended attributes:
> evm: security.selinux (disabled)
> evm: security.SMACK64 (disabled)
> evm: security.SMACK64EXEC (disabled)
> evm: security.SMACK64TRANSMUTE (disabled)
> evm: security.SMACK64MMAP (disabled)
> evm: security.apparmor
> evm: security.ima
> evm: security.capability
> evm: HMAC attrs: 0x1
> PM:   Magic number: 10:472:582
> tty ptyc0: hash matches
> netconsole: network logging started
> gtp: GTP module loaded (pdp ctx size 128 bytes)
> rdma_rxe: loaded
> cfg80211: Loading compiled-in X.509 certificates for regulatory database
> Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
> clk: Disabling unused clocks
> ALSA device list:
>   #0: Dummy 1
>   #1: Loopback 1
>   #2: Virtual MIDI Card 1
> check access for rdinit=/init failed: -2, ignoring
> md: Waiting for all devices to be available before autodetect
> md: If you don't use raid, use raid=noautodetect
> md: Autodetecting RAID arrays.
> md: autorun ...
> md: ... autorun DONE.
> EXT4-fs (sda1): mounted filesystem b4773fba-1738-4da0-8a90-0fe043d0a496 ro with ordered data mode. Quota mode: none.
> VFS: Mounted root (ext4 filesystem) readonly on device 8:1.
> devtmpfs: mounted
> Freeing unused kernel image (initmem) memory: 26044K
> Write protecting the kernel read-only data: 212992k
> Freeing unused kernel image (text/rodata gap) memory: 388K
> Freeing unused kernel image (rodata/data gap) memory: 1776K
> x86/mm: Checked W+X mappings: passed, no W+X pages found.
> x86/mm: Checking user space page tables
> x86/mm: Checked W+X mappings: passed, no W+X pages found.
> Failed to set sysctl parameter 'max_rcu_stall_to_panic=1': parameter not found
> Run /sbin/init as init process
> vma ffff888175272d80 start 00007fffffffe000 end 00007ffffffff000 mm ffff888100079880
> prot 8000000000000025 anon_vma ffff888110bf8000 vm_ops 0000000000000000
> pgoff 7fffffffe file 0000000000000000 private_data 0000000000000000
> refcnt 1
> flags: 0x8118173(read|write|mayread|maywrite|mayexec|growsdown|seqread|randread|account|softdirty)
> ------------[ cut here ]------------
> kernel BUG at ./include/linux/mmap_lock.h:476!
> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
> CPU: 0 UID: 0 PID: 1 Comm: init Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> RIP: 0010:anon_vma_name+0x253/0x260
> Code: ff 4c 89 ff e8 8e 7d 0a 00 e9 e9 fe ff ff e8 34 db a2 ff eb 0c e8 2d db a2 ff eb 05 e8 26 db a2 ff 48 89 df e8 6e 77 08 ff 90 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
> RSP: 0000:ffffc90000067550 EFLAGS: 00010286
> RAX: 000000000000014c RBX: ffff888175272d80 RCX: 37717524f4bb9000
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000004
> R10: dffffc0000000000 R11: fffffbfff1c3ae40 R12: dffffc0000000000
> R13: dffffc0000000000 R14: 0000000000000001 R15: 0000000000000001
> FS:  0000000000000000(0000) GS:ffff88818e405000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff88823ffff000 CR3: 0000000110c5a000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  vma_modify_flags+0x203/0x330
>  mprotect_fixup+0x46a/0xa50
>  setup_arg_pages+0x565/0xae0
>  load_elf_binary+0xc5e/0x2980
>  bprm_execve+0x93d/0x1410
>  kernel_execve+0x8ef/0x9e0
>  try_to_run_init_process+0x13/0x60
>  kernel_init+0xad/0x1d0
>  ret_from_fork+0x51b/0xa40
>  ret_from_fork_asm+0x1a/0x30
>  </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:anon_vma_name+0x253/0x260
> Code: ff 4c 89 ff e8 8e 7d 0a 00 e9 e9 fe ff ff e8 34 db a2 ff eb 0c e8 2d db a2 ff eb 05 e8 26 db a2 ff 48 89 df e8 6e 77 08 ff 90 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
> RSP: 0000:ffffc90000067550 EFLAGS: 00010286
> RAX: 000000000000014c RBX: ffff888175272d80 RCX: 37717524f4bb9000
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000004
> R10: dffffc0000000000 R11: fffffbfff1c3ae40 R12: dffffc0000000000
> R13: dffffc0000000000 R14: 0000000000000001 R15: 0000000000000001
> FS:  0000000000000000(0000) GS:ffff88818e405000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff88823ffff000 CR3: 0000000110c5a000 CR4: 00000000000006f0
>
>
> ***
>
> If these findings have caused you to resend the series or submit a
> separate fix, please add the following tag to your commit message:
>   Tested-by: syzbot@syzkaller.appspotmail.com
>
> ---
> This report is generated by a bot. It may contain errors.
> syzbot ci engineers can be reached at syzkaller@googlegroups.com.