Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Zorro Lang]

On Wed, Jun 08, 2022 at 09:13:12PM +0200, Alexander Gordeev wrote:
> On Wed, Jun 08, 2022 at 10:19:22AM +0800, Zorro Lang wrote:
> > One of the test environment details as [1]. The xfstests config as [2].
> > It's easier to reproduce on 64k directory size xfs by running xfstests
> > auto group.
> 
> 
> Thanks for the details, Zorro!
> 
> Do you create test and scratch device with xfs_io, as README suggests?
> If yes, what are sizes of the files?
> Also, do you run always xfs/auto or xfs/294 hits for you reliably?

Looks likt it's not a s390x specific bug, I just hit this issue once (not 100%
reproducible) on aarch64 with linux v5.19.0-rc1+ [1]. So back to cc linux-mm
to get more review.

Thanks,
Zorro

[1]
[  980.200947] usercopy: Kernel memory exposure attempt detected from vmalloc 'no area' (offset 0, size 1)! 
[  980.200968] ------------[ cut here ]------------ 
[  980.200969] kernel BUG at mm/usercopy.c:101! 
[  980.201081] Internal error: Oops - BUG: 0 [#1] SMP 
[  980.224192] Modules linked in: rfkill arm_spe_pmu mlx5_ib ast drm_vram_helper drm_ttm_helper ttm ib_uverbs acpi_ipmi drm_kms_helper ipmi_ssif fb_sys_fops syscopyarea sysfillrect ib_core sysimgblt arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq sunrpc vfat fat drm fuse xfs libcrc32c mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt nvme igb mlxfw nvme_core tls i2c_algo_bit psample pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon ipmi_devintf ipmi_msghandler 
[  980.268449] CPU: 42 PID: 121940 Comm: rm Kdump: loaded Not tainted 5.19.0-rc1+ #1 
[  980.275921] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F16f (SCP: 1.06.20210615) 07/01/2021 
[  980.285214] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) 
[  980.292165] pc : usercopy_abort+0x78/0x7c 
[  980.296167] lr : usercopy_abort+0x78/0x7c 
[  980.300166] sp : ffff80002b007730 
[  980.303469] x29: ffff80002b007740 x28: ffff80002b007cc0 x27: ffffdc5683ecc880 
[  980.310595] x26: 1ffff00005600f9b x25: ffffdc5681c90000 x24: ffff80002b007cdc 
[  980.317722] x23: ffff800041a0004a x22: 0000000000000001 x21: 0000000000000001 
[  980.324848] x20: 0000000000000000 x19: ffff800041a00049 x18: 0000000000000000 
[  980.331974] x17: 2720636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 
[  980.339101] x14: 74706d6574746120 x13: 21293120657a6973 x12: ffff6106cbc4c03f 
[  980.346227] x11: 1fffe106cbc4c03e x10: ffff6106cbc4c03e x9 : ffffdc5681f36e30 
[  980.353353] x8 : ffff08365e2601f7 x7 : 0000000000000001 x6 : ffff6106cbc4c03e 
[  980.360480] x5 : ffff08365e2601f0 x4 : 1fffe10044b11801 x3 : 0000000000000000 
[  980.367606] x2 : 0000000000000000 x1 : ffff08022588c000 x0 : 000000000000005c 
[  980.374733] Call trace: 
[  980.377167]  usercopy_abort+0x78/0x7c 
[  980.380819]  check_heap_object+0x3dc/0x3e0 
[  980.384907]  __check_object_size.part.0+0x6c/0x1f0 
[  980.389688]  __check_object_size+0x24/0x30 
[  980.393774]  filldir64+0x548/0x84c 
[  980.397165]  xfs_dir2_block_getdents+0x404/0x960 [xfs] 
[  980.402437]  xfs_readdir+0x3c4/0x4b0 [xfs] 
[  980.406652]  xfs_file_readdir+0x6c/0xa0 [xfs] 
[  980.411127]  iterate_dir+0x3a4/0x500 
[  980.414691]  __do_sys_getdents64+0xb0/0x230 
[  980.418863]  __arm64_sys_getdents64+0x70/0xa0 
[  980.423209]  invoke_syscall.constprop.0+0xd8/0x1d0 
[  980.427991]  el0_svc_common.constprop.0+0x224/0x2bc 
[  980.432858]  do_el0_svc+0x4c/0x90 
[  980.436163]  el0_svc+0x5c/0x140 
[  980.439294]  el0t_64_sync_handler+0xb4/0x130 
[  980.443553]  el0t_64_sync+0x174/0x178 
[  980.447206] Code: f90003e3 aa0003e3 91098100 97ffe24b (d4210000)  
[  980.453292] SMP: stopping secondary CPUs 
[  980.458162] Starting crashdump kernel... 
[  980.462073] Bye!

> 
> Thanks!
> 

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Matthew Wilcox]

On Sun, Jun 12, 2022 at 12:42:30PM +0800, Zorro Lang wrote:
> Looks likt it's not a s390x specific bug, I just hit this issue once (not 100%
> reproducible) on aarch64 with linux v5.19.0-rc1+ [1]. So back to cc linux-mm
> to get more review.
> 
> [1]
> [  980.200947] usercopy: Kernel memory exposure attempt detected from vmalloc 'no area' (offset 0, size 1)! 

       if (is_vmalloc_addr(ptr)) {
               struct vm_struct *area = find_vm_area(ptr);
               if (!area) {
                       usercopy_abort("vmalloc", "no area", to_user, 0, n);

Oh.  Looks like XFS uses vm_map_ram() and vm_map_ram() doesn't allocate
a vm_struct.

Ulad, how does this look to you?

diff --git a/mm/usercopy.c b/mm/usercopy.c
index baeacc735b83..6bc2a1407c59 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -173,7 +173,7 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
 	}
 
 	if (is_vmalloc_addr(ptr)) {
-		struct vm_struct *area = find_vm_area(ptr);
+		struct vmap_area *area = find_vmap_area((unsigned long)ptr);
 		unsigned long offset;
 
 		if (!area) {
@@ -181,8 +181,9 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
 			return;
 		}
 
-		offset = ptr - area->addr;
-		if (offset + n > get_vm_area_size(area))
+		/* XXX: We should also abort for free vmap_areas */
+		offset = (unsigned long)ptr - area->va_start;
+		if (offset + n >= area->va_end)
 			usercopy_abort("vmalloc", NULL, to_user, offset, n);
 		return;
 	}
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 07db42455dd4..effd1ff6a4b4 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1798,7 +1798,7 @@ static void free_unmap_vmap_area(struct vmap_area *va)
 	free_vmap_area_noflush(va);
 }
 
-static struct vmap_area *find_vmap_area(unsigned long addr)
+struct vmap_area *find_vmap_area(unsigned long addr)
 {
 	struct vmap_area *va;
 

> [  980.200968] ------------[ cut here ]------------ 
> [  980.200969] kernel BUG at mm/usercopy.c:101! 
> [  980.201081] Internal error: Oops - BUG: 0 [#1] SMP 
> [  980.224192] Modules linked in: rfkill arm_spe_pmu mlx5_ib ast drm_vram_helper drm_ttm_helper ttm ib_uverbs acpi_ipmi drm_kms_helper ipmi_ssif fb_sys_fops syscopyarea sysfillrect ib_core sysimgblt arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq sunrpc vfat fat drm fuse xfs libcrc32c mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt nvme igb mlxfw nvme_core tls i2c_algo_bit psample pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon ipmi_devintf ipmi_msghandler 
> [  980.268449] CPU: 42 PID: 121940 Comm: rm Kdump: loaded Not tainted 5.19.0-rc1+ #1 
> [  980.275921] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F16f (SCP: 1.06.20210615) 07/01/2021 
> [  980.285214] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) 
> [  980.292165] pc : usercopy_abort+0x78/0x7c 
> [  980.296167] lr : usercopy_abort+0x78/0x7c 
> [  980.300166] sp : ffff80002b007730 
> [  980.303469] x29: ffff80002b007740 x28: ffff80002b007cc0 x27: ffffdc5683ecc880 
> [  980.310595] x26: 1ffff00005600f9b x25: ffffdc5681c90000 x24: ffff80002b007cdc 
> [  980.317722] x23: ffff800041a0004a x22: 0000000000000001 x21: 0000000000000001 
> [  980.324848] x20: 0000000000000000 x19: ffff800041a00049 x18: 0000000000000000 
> [  980.331974] x17: 2720636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 
> [  980.339101] x14: 74706d6574746120 x13: 21293120657a6973 x12: ffff6106cbc4c03f 
> [  980.346227] x11: 1fffe106cbc4c03e x10: ffff6106cbc4c03e x9 : ffffdc5681f36e30 
> [  980.353353] x8 : ffff08365e2601f7 x7 : 0000000000000001 x6 : ffff6106cbc4c03e 
> [  980.360480] x5 : ffff08365e2601f0 x4 : 1fffe10044b11801 x3 : 0000000000000000 
> [  980.367606] x2 : 0000000000000000 x1 : ffff08022588c000 x0 : 000000000000005c 
> [  980.374733] Call trace: 
> [  980.377167]  usercopy_abort+0x78/0x7c 
> [  980.380819]  check_heap_object+0x3dc/0x3e0 
> [  980.384907]  __check_object_size.part.0+0x6c/0x1f0 
> [  980.389688]  __check_object_size+0x24/0x30 
> [  980.393774]  filldir64+0x548/0x84c 
> [  980.397165]  xfs_dir2_block_getdents+0x404/0x960 [xfs] 
> [  980.402437]  xfs_readdir+0x3c4/0x4b0 [xfs] 
> [  980.406652]  xfs_file_readdir+0x6c/0xa0 [xfs] 
> [  980.411127]  iterate_dir+0x3a4/0x500 

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Uladzislau Rezki]

> On Sun, Jun 12, 2022 at 12:42:30PM +0800, Zorro Lang wrote:
> > Looks likt it's not a s390x specific bug, I just hit this issue once (not 100%
> > reproducible) on aarch64 with linux v5.19.0-rc1+ [1]. So back to cc linux-mm
> > to get more review.
> > 
> > [1]
> > [  980.200947] usercopy: Kernel memory exposure attempt detected from vmalloc 'no area' (offset 0, size 1)! 
> 
>        if (is_vmalloc_addr(ptr)) {
>                struct vm_struct *area = find_vm_area(ptr);
>                if (!area) {
>                        usercopy_abort("vmalloc", "no area", to_user, 0, n);
> 
> Oh.  Looks like XFS uses vm_map_ram() and vm_map_ram() doesn't allocate
> a vm_struct.
> 
> Ulad, how does this look to you?
>
It looks like a correct way to me :) XFS uses per-cpu-vm_map_ram()-vm_unmap_ram()
API which do not allocate "vm_struct" because it is not needed.

>
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> index baeacc735b83..6bc2a1407c59 100644
> --- a/mm/usercopy.c
> +++ b/mm/usercopy.c
> @@ -173,7 +173,7 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
>  	}
>  
>  	if (is_vmalloc_addr(ptr)) {
> -		struct vm_struct *area = find_vm_area(ptr);
> +		struct vmap_area *area = find_vmap_area((unsigned long)ptr);
>  		unsigned long offset;
>  
>  		if (!area) {
> @@ -181,8 +181,9 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
>  			return;
>  		}
>  
> -		offset = ptr - area->addr;
> -		if (offset + n > get_vm_area_size(area))
> +		/* XXX: We should also abort for free vmap_areas */
> +		offset = (unsigned long)ptr - area->va_start;
>
I was a bit confused about "offset" and why it is needed here. It is always zero. 
So we can get rid of it to make it less confused. From the other hand a zero offset
contributes to nothing.

>
> +		if (offset + n >= area->va_end)
>
I think it is a bit wrong. As i see it, "n" is a size and what we would like to do
here is boundary check:

<snip>
if (n > va_size(area))
    usercopy_abort("vmalloc", NULL, to_user, 0, n);
<snip>

--
Uladzislau Rezki

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Matthew Wilcox]

On Sun, Jun 12, 2022 at 03:03:20PM +0200, Uladzislau Rezki wrote:
> > @@ -181,8 +181,9 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
> >  			return;
> >  		}
> >  
> > -		offset = ptr - area->addr;
> > -		if (offset + n > get_vm_area_size(area))
> > +		/* XXX: We should also abort for free vmap_areas */
> > +		offset = (unsigned long)ptr - area->va_start;
> >
> I was a bit confused about "offset" and why it is needed here. It is always zero. 
> So we can get rid of it to make it less confused. From the other hand a zero offset
> contributes to nothing.

I don't think offset is necessarily zero.  'ptr' is a pointer somewhere
in the object, not necessarily the start of the object.

> >
> > +		if (offset + n >= area->va_end)
> >
> I think it is a bit wrong. As i see it, "n" is a size and what we would like to do
> here is boundary check:
> 
> <snip>
> if (n > va_size(area))
>     usercopy_abort("vmalloc", NULL, to_user, 0, n);
> <snip>

Hmm ... we should probably be more careful about wrapping.

                if (n > area->va_end - addr)
                        usercopy_abort("vmalloc", NULL, to_user, offset, n);

... and that goes for the whole function actually.  I'll split that into
a separate change.

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Yu Zhao]

On Sun, Jun 12, 2022 at 11:27 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Jun 12, 2022 at 03:03:20PM +0200, Uladzislau Rezki wrote:
> > > @@ -181,8 +181,9 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
> > >                     return;
> > >             }
> > >
> > > -           offset = ptr - area->addr;
> > > -           if (offset + n > get_vm_area_size(area))
> > > +           /* XXX: We should also abort for free vmap_areas */
> > > +           offset = (unsigned long)ptr - area->va_start;
> > >
> > I was a bit confused about "offset" and why it is needed here. It is always zero.
> > So we can get rid of it to make it less confused. From the other hand a zero offset
> > contributes to nothing.
>
> I don't think offset is necessarily zero.  'ptr' is a pointer somewhere
> in the object, not necessarily the start of the object.
>
> > >
> > > +           if (offset + n >= area->va_end)
> > >
> > I think it is a bit wrong. As i see it, "n" is a size and what we would like to do
> > here is boundary check:
> >
> > <snip>
> > if (n > va_size(area))
> >     usercopy_abort("vmalloc", NULL, to_user, 0, n);
> > <snip>
>
> Hmm ... we should probably be more careful about wrapping.
>
>                 if (n > area->va_end - addr)
>                         usercopy_abort("vmalloc", NULL, to_user, offset, n);
>
> ... and that goes for the whole function actually.  I'll split that into
> a separate change.

Please let me know if there is something we want to test -- I can
reproduce the problem reliably:

------------[ cut here ]------------
kernel BUG at mm/usercopy.c:101!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
CPU: 4 PID: 3259 Comm: iptables Not tainted 5.19.0-rc1-lockdep+ #1
pc : usercopy_abort+0x9c/0xa0
lr : usercopy_abort+0x9c/0xa0
sp : ffffffc010bd78d0
x29: ffffffc010bd78e0 x28: 42ffff80ac08d8ec x27: 42ffff80ac08d8ec
x26: 42ffff80ac08d8c0 x25: 000000000000000a x24: ffffffdf4c7e5120
x23: 000000000bec44c2 x22: efffffc000000000 x21: ffffffdf2896b0c0
x20: 0000000000000001 x19: 000000000000000b x18: 0000000000000000
x17: 2820636f6c6c616d x16: 0000000000000042 x15: 6574636574656420
x14: 74706d6574746120 x13: 0000000000000018 x12: 000000000000000d
x11: ff80007fffffffff x10: 0000000000000001 x9 : db174b7f89103400
x8 : db174b7f89103400 x7 : 0000000000000000 x6 : 79706f6372657375
x5 : ffffffdf4d9c617e x4 : 0000000000000000 x3 : ffffffdf4b7d017c
x2 : ffffff80eb188b18 x1 : 42ffff80ac08d8c8 x0 : 0000000000000066
Call trace:
 usercopy_abort+0x9c/0xa0
 __check_object_size+0x38c/0x400
 xt_obj_to_user+0xe4/0x200
 xt_compat_target_to_user+0xd8/0x18c
 compat_copy_entries_to_user+0x278/0x424
 do_ipt_get_ctl+0x7bc/0xb2c
 nf_getsockopt+0x7c/0xb4
 ip_getsockopt+0xee8/0xfa4
 raw_getsockopt+0xf4/0x23c
 sock_common_getsockopt+0x48/0x54
 __sys_getsockopt+0x11c/0x2f8
 __arm64_sys_getsockopt+0x60/0x70
 el0_svc_common+0xfc/0x1cc
 do_el0_svc_compat+0x38/0x5c
 el0_svc_compat+0x68/0xf4
 el0t_32_sync_handler+0xc0/0xf0
 el0t_32_sync+0x190/0x194
Code: aa0903e4 a9017bfd 910043fd 9438be18 (d4210000)
---[ end trace 0000000000000000 ]---

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Matthew Wilcox]

On Sun, Jun 12, 2022 at 11:59:58AM -0600, Yu Zhao wrote:
> Please let me know if there is something we want to test -- I can
> reproduce the problem reliably:
> 
> ------------[ cut here ]------------
> kernel BUG at mm/usercopy.c:101!

The line right before cut here would have been nice ;-)

https://lore.kernel.org/linux-mm/YqXU+oU7wayOcmCe@casper.infradead.org/

might fix your problem, but I can't be sure without that line.

> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> CPU: 4 PID: 3259 Comm: iptables Not tainted 5.19.0-rc1-lockdep+ #1
> pc : usercopy_abort+0x9c/0xa0
> lr : usercopy_abort+0x9c/0xa0
> sp : ffffffc010bd78d0
> x29: ffffffc010bd78e0 x28: 42ffff80ac08d8ec x27: 42ffff80ac08d8ec
> x26: 42ffff80ac08d8c0 x25: 000000000000000a x24: ffffffdf4c7e5120
> x23: 000000000bec44c2 x22: efffffc000000000 x21: ffffffdf2896b0c0
> x20: 0000000000000001 x19: 000000000000000b x18: 0000000000000000
> x17: 2820636f6c6c616d x16: 0000000000000042 x15: 6574636574656420
> x14: 74706d6574746120 x13: 0000000000000018 x12: 000000000000000d
> x11: ff80007fffffffff x10: 0000000000000001 x9 : db174b7f89103400
> x8 : db174b7f89103400 x7 : 0000000000000000 x6 : 79706f6372657375
> x5 : ffffffdf4d9c617e x4 : 0000000000000000 x3 : ffffffdf4b7d017c
> x2 : ffffff80eb188b18 x1 : 42ffff80ac08d8c8 x0 : 0000000000000066
> Call trace:
>  usercopy_abort+0x9c/0xa0
>  __check_object_size+0x38c/0x400
>  xt_obj_to_user+0xe4/0x200
>  xt_compat_target_to_user+0xd8/0x18c
>  compat_copy_entries_to_user+0x278/0x424
>  do_ipt_get_ctl+0x7bc/0xb2c
>  nf_getsockopt+0x7c/0xb4
>  ip_getsockopt+0xee8/0xfa4
>  raw_getsockopt+0xf4/0x23c
>  sock_common_getsockopt+0x48/0x54
>  __sys_getsockopt+0x11c/0x2f8
>  __arm64_sys_getsockopt+0x60/0x70
>  el0_svc_common+0xfc/0x1cc
>  do_el0_svc_compat+0x38/0x5c
>  el0_svc_compat+0x68/0xf4
>  el0t_32_sync_handler+0xc0/0xf0
>  el0t_32_sync+0x190/0x194
> Code: aa0903e4 a9017bfd 910043fd 9438be18 (d4210000)
> ---[ end trace 0000000000000000 ]---

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Yu Zhao]

On Sun, Jun 12, 2022 at 12:05 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Jun 12, 2022 at 11:59:58AM -0600, Yu Zhao wrote:
> > Please let me know if there is something we want to test -- I can
> > reproduce the problem reliably:
> >
> > ------------[ cut here ]------------
> > kernel BUG at mm/usercopy.c:101!
>
> The line right before cut here would have been nice ;-)

Right.

$ grep usercopy:
usercopy: Kernel memory exposure attempt detected from vmalloc (offset
2882303761517129920, size 11)!
usercopy: Kernel memory exposure attempt detected from vmalloc (offset
8574853690513436864, size 11)!
usercopy: Kernel memory exposure attempt detected from vmalloc (offset
7998392938210013376, size 11)!
...

> https://lore.kernel.org/linux-mm/YqXU+oU7wayOcmCe@casper.infradead.org/
>
> might fix your problem, but I can't be sure without that line.

Thanks, it worked!

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Matthew Wilcox]

On Sun, Jun 12, 2022 at 12:43:45PM -0600, Yu Zhao wrote:
> On Sun, Jun 12, 2022 at 12:05 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Sun, Jun 12, 2022 at 11:59:58AM -0600, Yu Zhao wrote:
> > > Please let me know if there is something we want to test -- I can
> > > reproduce the problem reliably:
> > >
> > > ------------[ cut here ]------------
> > > kernel BUG at mm/usercopy.c:101!
> >
> > The line right before cut here would have been nice ;-)
> 
> Right.
> 
> $ grep usercopy:
> usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> 2882303761517129920, size 11)!
> usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> 8574853690513436864, size 11)!
> usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> 7998392938210013376, size 11)!

That's a different problem.  And, er, what?  How on earth do we have
an offset that big?!

                struct vm_struct *area = find_vm_area(ptr);
                offset = ptr - area->addr;
                if (offset + n > get_vm_area_size(area))
                        usercopy_abort("vmalloc", NULL, to_user, offset, n);

That first offset is 0x2800'0000'0000'30C0

You said it was easy to replicate; can you add:

			printk("addr:%px ptr:%px\n", area->addr, ptr);

so that we can start to understand how we end up with such a bogus
offset?

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Yu Zhao]

On Sun, Jun 12, 2022 at 1:52 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Jun 12, 2022 at 12:43:45PM -0600, Yu Zhao wrote:
> > On Sun, Jun 12, 2022 at 12:05 PM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Sun, Jun 12, 2022 at 11:59:58AM -0600, Yu Zhao wrote:
> > > > Please let me know if there is something we want to test -- I can
> > > > reproduce the problem reliably:
> > > >
> > > > ------------[ cut here ]------------
> > > > kernel BUG at mm/usercopy.c:101!
> > >
> > > The line right before cut here would have been nice ;-)
> >
> > Right.
> >
> > $ grep usercopy:
> > usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> > 2882303761517129920, size 11)!
> > usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> > 8574853690513436864, size 11)!
> > usercopy: Kernel memory exposure attempt detected from vmalloc (offset
> > 7998392938210013376, size 11)!
>
> That's a different problem.  And, er, what?  How on earth do we have
> an offset that big?!
>
>                 struct vm_struct *area = find_vm_area(ptr);
>                 offset = ptr - area->addr;
>                 if (offset + n > get_vm_area_size(area))
>                         usercopy_abort("vmalloc", NULL, to_user, offset, n);
>
> That first offset is 0x2800'0000'0000'30C0
>
> You said it was easy to replicate; can you add:
>
>                         printk("addr:%px ptr:%px\n", area->addr, ptr);
>
> so that we can start to understand how we end up with such a bogus
> offset?

Here you go:

addr:96ffffdfebcd4000 ptr:ffffffdfebcd70c0
usercopy: Kernel memory exposure attempt detected from vmalloc (offset
7566047373982445760, size 11)!

And, not sure if it'd be helpful, with the vmap:

va_start:ffffffd83db0d000 va_end:ffffffd83db13000
addr:44ffffd83db0d000 ptr:ffffffd83db100c0
usercopy: Kernel memory exposure attempt detected from vmalloc (offset
13474770085092536512, size 11)!

which seems to explain why the fix worked.

+               if (offset + n > get_vm_area_size(area)) {
+                       struct vmap_area *vmap =
find_vmap_area((unsigned long)ptr);
+
+                       if (vmap)
+                               printk("va_start:%px va_end:%px\n",
vmap->va_start, vmap->va_end);
+                       printk("addr:%px ptr:%px\n", area->addr, ptr);
                        usercopy_abort("vmalloc", NULL, to_user, offset, n);
+               }

Re: [Bug 216073] New: [s390x] kernel BUG at mm/usercopy.c:101! usercopy: Kernel memory exposure attempt detected from vmalloc 'n o area' (offset 0, size 1)!

[Uladzislau Rezki]

> On Sun, Jun 12, 2022 at 03:03:20PM +0200, Uladzislau Rezki wrote:
> > > @@ -181,8 +181,9 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
> > >  			return;
> > >  		}
> > >  
> > > -		offset = ptr - area->addr;
> > > -		if (offset + n > get_vm_area_size(area))
> > > +		/* XXX: We should also abort for free vmap_areas */
> > > +		offset = (unsigned long)ptr - area->va_start;
> > >
> > I was a bit confused about "offset" and why it is needed here. It is always zero. 
> > So we can get rid of it to make it less confused. From the other hand a zero offset
> > contributes to nothing.
> 
> I don't think offset is necessarily zero.  'ptr' is a pointer somewhere
> in the object, not necessarily the start of the object.
> 
Right you are. Just checked the __find_vmap_area() it returns VA of the address it
belongs to. Initially i was thinking that addr have to be exactly as va->start only,
so i was wrong.

> > >
> > > +		if (offset + n >= area->va_end)
> > >
> > I think it is a bit wrong. As i see it, "n" is a size and what we would like to do
> > here is boundary check:
> > 
> > <snip>
> > if (n > va_size(area))
> >     usercopy_abort("vmalloc", NULL, to_user, 0, n);
> > <snip>
> 
> Hmm ... we should probably be more careful about wrapping.
> 
>                 if (n > area->va_end - addr)
>                         usercopy_abort("vmalloc", NULL, to_user, offset, n);
> 
> ... and that goes for the whole function actually.  I'll split that into
> a separate change.
> 
Based on that offset can be > 0, checking "offset + n" with va->va_end is OK.

<snip>
if (offset + n > area->va_end)
    usercopy_abort("vmalloc", NULL, to_user, offset, n);
<snip>

--
Uladzislau Rezki