linux-kernel - Re: Crash when user space allocates non-highmem memory

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] [day] [month] [year] [list]

Message-ID: <aEHZAGThzCdvvF3O@colin-ia-desktop>
Date: Thu, 5 Jun 2025 12:50:56 -0500
From: Colin Foster <colin.foster@...advantage.com>
To: linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org
Subject: Re: Crash when user space allocates non-highmem memory

On Tue, May 27, 2025 at 02:49:20PM -0500, Colin Foster wrote:
> Hello,
> 
> I'm running up against a reliable failure mode on my hardware and want
> to see if there are any suggestions for tracking down what might be
> going on.
> 
> The kernel is currently 6.12.28, with essentially no out-of-tree patches
> besides our DTS. The hardware is an OMAP 4460 processor.
> 
> The behavior I see is quite repeatable. I can allocate about 220MB of
> RAM by running:
> 
> dd if=/dev/zero of=/tmp/myfile1 bs=1M count=220

I figure I'd add more info about my issue.

A slight modification to "memhog" means I can essentially track one page
at a time. It leads to the following behavior:

mmap(250MB);
memset(addr, 0xff, 4096);

I can step in GDB over my application and trace page allocation one at
a time.

The PFN around 0x8fd3f should be available... 'page-types -l' reports a
huge block available, as far as I understand:

82c88   38      ____________________________________________
82cc0   d190    __________B_________________________________
8fe50   1       __________B_________________________________

However, it seems clear that some memory in that range is, in
fact, in use. 'memset' will eventually cause a crash around that area,
as will running 'devmem', 'dd /dev/mem'.

The output of /proc/vmallocinfo has me scratching my head. I'm not sure
if this type of output (the second address) is expected, or an
indication of something going terribly wrong:

0x887646e9-0xb6c38d9d   12288 kernel_clone+0xb0/0x414 pages=2 vmalloc
0x8d918e2e-0x0f0cf24b    8192 load_module+0x6ec/0x1e2c pages=1 vmalloc
0x8eadfe6c-0x2c2bdafa   12288 load_module+0x6ec/0x1e2c pages=2 vmalloc
0x90bdaef9-0x73aeced1   36864 pcpu_create_chunk+0x208/0x2a0 pages=8 vmalloc
0x93acc2a4-0x5c7fff68   12288 __devm_ioremap_resource+0x150/0x1dc phys=0x44800000 ioremap
0x950bf861-0xd3df2ba7   12288 kernel_clone+0xb0/0x414 pages=2 vmalloc

So I suppose I have an open question:

Is there a way to tell what might be mapped in that specific region?
It seems clear that it is _something_, but there is some MMU / virtual
memory misconfiguration that makes DDR that is supposed to be in one
area actually use the memory in a different area.

Once I figure out exactly "what" is in that region, it should hopefully
be easy for me to track down "why" it is there. Any nudge for someone
with little knowledge at VM layer could go a long way.

Thanks,

Colin