linux-kernel - Re: Bug related with a 6.6.24 platform/x86 commit signed by you

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f055fd4d-7ee7-40b9-a394-5cc8bfe52c97@suswa.mountain>
Date: Fri, 19 Jul 2024 10:01:14 -0500
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
	Max Dubois <makemehappy@...ketmail.com>,
	"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	Dan Carpenter <error27@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Bug related with a 6.6.24 platform/x86 commit signed by you -
 Enormous memory leak

On Fri, Jul 19, 2024 at 02:32:15PM +0200, Thomas Weißschuh wrote:
> On Fri, Jul 19, 2024 at 05:34:23PM GMT, Harshit Mogalapalli wrote:
> The reporting really should figure out which specific release or commit
> is introducing the issue. And if mainline or 6.6.41 are also affected.
> 
> The linked gentoo forum thread has some actual kernel logs:
> 
> Jul 16 00:01:10 [kernel] alloc_vmap_area: 133 callbacks suppressed
> Jul 16 00:01:10 [kernel] vmap allocation for size 20480 failed: use vmalloc=<size> to increase size
>                 - Last output repeated 9 times -
> Jul 16 00:01:15 [kernel] alloc_vmap_area: 240 callbacks suppressed
> Jul 16 00:01:15 [kernel] vmap allocation for size 20480 failed: use vmalloc=<size> to increase size
>                 - Last output repeated 9 times -
> Jul 16 00:01:17 [kernel] warn_alloc: 3 callbacks suppressed
> Jul 16 00:01:17 [kernel] Web Content: vmalloc error: size 8192, vm_struct allocation failed, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0
> Jul 16 00:01:17 [kernel] CPU: 1 PID: 2761 Comm: Web Content Not tainted 6.6.38-gentoo #1
> Jul 16 00:01:17 [kernel] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B32.2305221830 05/22/2023
> Jul 16 00:01:17 [kernel] Call Trace:
> Jul 16 00:01:17 [kernel]  dump_stack_lvl+0x32/0x41
> Jul 16 00:01:17 [kernel]  dump_stack+0xd/0x10
> Jul 16 00:01:17 [kernel]  warn_alloc+0xab/0x111
> Jul 16 00:01:17 [kernel]  __vmalloc_node_range+0x73/0x345
> Jul 16 00:01:17 [kernel]  __vmalloc_node+0x55/0x5d
> Jul 16 00:01:17 [kernel]  ? bpf_prog_alloc_no_stats+0x1f/0xcd
> Jul 16 00:01:17 [kernel]  __vmalloc+0x14/0x16
> Jul 16 00:01:17 [kernel]  ? bpf_prog_alloc_no_stats+0x1f/0xcd
> Jul 16 00:01:17 [kernel]  bpf_prog_alloc_no_stats+0x1f/0xcd
> Jul 16 00:01:17 [kernel]  bpf_prog_alloc+0x13/0x9f
> Jul 16 00:01:17 [kernel]  bpf_prog_create_from_user+0x47/0xbd
> Jul 16 00:01:17 [kernel]  ? kprobe_free_init_mem+0x4c/0x4c
> Jul 16 00:01:17 [kernel]  do_seccomp+0x176/0x7ac
> Jul 16 00:01:17 [kernel]  ? __ia32_sys_prctl+0x47/0x5bf
> Jul 16 00:01:17 [kernel]  __ia32_sys_seccomp+0x10/0x12
> Jul 16 00:01:17 [kernel]  ia32_sys_call+0xd09/0x1063
> Jul 16 00:01:17 [kernel]  __do_fast_syscall_32+0x7a/0x99
> Jul 16 00:01:17 [kernel]  do_fast_syscall_32+0x29/0x5b
> Jul 16 00:01:17 [kernel]  do_SYSENTER_32+0x15/0x17
> Jul 16 00:01:17 [kernel]  entry_SYSENTER_32+0x98/0xf8
> Jul 16 00:01:17 [kernel] EIP: 0xb7fc856d
> 
> The lines with "size 20480" repeat *a lot*, it could be the issue.
> 

The interesting thing about that is the working kernel had tons of these
allocation failures as well.
https://bugzilla.kernel.org/show_bug.cgi?id=219061
See the attachment which called "This is a session with the last WORKING
KERNEL 6.6.23, NO ERRORS, everything fine".

I don't think the problem is Harshit's patch.  It should be easy enough
to do a `git show 9a98ab01e3ac | patch -p1  -R` and test the results.
If that doesn't fix the bug, then it would be nice to do a git bisect
between v6.6.23 and v6.6.24.

regards,
dan carpenter