* [PATCH v2] mm/secretmem: don't allow highmem folios
@ 2026-07-17 9:48 Brendan Jackman
2026-07-17 12:03 ` David Hildenbrand (Arm)
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Brendan Jackman @ 2026-07-17 9:48 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko
Cc: linux-mm, linux-kernel, brendan.jackman, Brendan Jackman
secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls
set_direct_map_invalid_noflush() without checking folio_test_highmem().
This causes a warning and process crash (vibe-coded reproducer in Link
below):
Su[ 30.071284] ------------[ cut here ]------------
ccessfully allocated and mapped 2097152000 bytes at 0x3a449000
Populating memor[ 30.074614] CPA: called for zero pte. vaddr = 0 cpa->vaddr = 0
y...
[ 30.078636] WARNING: arch/x86/mm/pat/set_memory.c:1840 at __cpa_process_fault+0x34d/0x360, CPU#5: allocate_secret/570
[ 30.084789] CPU: 5 UID: 0 PID: 570 Comm: allocate_secret Not tainted 7.1.0-14063-g4edcdefd4083-dirty #10 PREEMPTLAZY
[ 30.090937] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
[ 30.097543] EIP: __cpa_process_fault+0x34d/0x360
[ 30.100514] Code: ff ff 85 c0 0f 89 7d fe ff ff e9 3d fe ff ff 8b 03 8b 00 c7 04 24 c8 ff 64 c1 89 44 24 08 8b 45 e8 89 44 24 04 e8 53 7
a 00 00 <0f> 0b c7 45 f0 f2 ff ff ff e9 fc fc ff ff 90 8d 74 26 00 55 25 00
[ 30.110829] EAX: 00000000 EBX: f64afe98 ECX: 00000000 EDX: 00000000
[ 30.114799] ESI: 00000000 EDI: f64afe98 EBP: f64afe04 ESP: f64afdcc
[ 30.118785] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010246
[ 30.123020] CR0: 80050033 CR2: 46c48ffc CR3: 038c8000 CR4: 00000690
[ 30.127010] Call Trace:
[ 30.129078] __change_page_attr_set_clr+0x5e7/0x870
[ 30.132275] ? console_unlock+0x99/0x130
[ 30.135069] ? irq_work_queue+0x36/0x70
[ 30.137853] ? page_address+0xd3/0xf0
[ 30.140421] set_direct_map_invalid_noflush+0x52/0x60
[ 30.143782] secretmem_fault+0x128/0x210
[ 30.146560] __do_fault+0x25/0x90
[ 30.149053] handle_mm_fault+0x6d1/0xcb0
[ 30.151759] exc_page_fault+0x135/0x3b0
[ 30.154487] ? doublefault_shim+0x150/0x150
[ 30.157416] handle_exception+0x130/0x130
[ 30.160137] EIP: 0x804d29f
[ 30.162307] Code: 89 54 08 e1 89 54 08 e5 89 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 0
0 00 00 <89> 44 0f fc 75 0e c1 e9 02 f3 ab 8b 44 24 04 8b 7c 24 0c c3 31 d2
[ 30.172936] EAX: 5a5a5a5a EBX: 00000000 ECX: 0c800000 EDX: 3a449000
[ 30.176927] ESI: 00000000 EDI: 3a449000 EBP: bfbbae18 ESP: bfbbadac
[ 30.180897] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010246
[ 30.185161] ? doublefault_shim+0x150/0x150
[ 30.187979] ---[ end trace 0000000000000000 ]---
Bus error (core dumped) ./allocate_secret_i686 2000M
The equivalent bug was pointed out by a local Sashiko instance on
https://lore.kernel.org/all/20260410151746.61150-3-kalyazin@amazon.com/
This hasn't been reproduced it on older kernel versions but from code
inspection the bug seems to go back to the original introduction in
commit 1507f51255c9f ("mm: introduce memfd_secret system call to create
"secret" memory areas"). If this configuration has always been broken,
there's no need to worry too much about feature regression here.
Nonetheless, instead of just completely disabling secretmem under
!HIGHMEM, just drop __GFP_HIGHMEM. This means that now where you
previously got a crash, instead you'll just see the secretmem process
OOM.
Could secretmem just support highmem by saying "this isn't in the direct
map anyway" and bailing out before the set_direct_map_invalid_noflush()?
Maybe. That depends on requirements that are not well-defined (e.g. is
it OK that kmap_local_page() is not a NOP for those pages?), and would
require some research and deep thinking. Let's "defer" that until
an actual usecase arises.
Link: https://github.com/bjackman/limmat-kernel-nix/commit/7b2acba2d3a5ef01400d493a155beb1d135b6bb5
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org/
Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "secret" memory areas")
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Based on mm-new with `[PATCH] mm/secretmem: disable under HIGHMEM` [1]
reverted.
Note this was found by Sashiko but in a local instance, so I can't
provide a link to the report and I guess it's technically inaccurate to
mention sashiko-bot@kernel.org.
I wrote in [0] that I needed to compile a 32bit OS but I was wrong, the
build is already done and this is tested on QEMU, the vibe-coded repro
linked in the patch now gets OOM-killed as appropriate:
Populated 838860800/2097152000 bytes (40%)...
[ 202.930157] allocate_secret invoked oom-killer: gfp_mask=0x140dc0(GFP_USER|__GFP_ZERO|__GFP_COMP), order=0, oom_score_adj=0
[ 202.937102] CPU: 1 UID: 0 PID: 588 Comm: allocate_secret Not tainted 7.2.0-rc2-00579-g00ba42d1257f #56 PREEMPTLAZY
[ 202.937105] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
[ 202.937106] Call Trace:
[ 202.937108] dump_stack_lvl+0x44/0x64
[ 202.937112] dump_stack+0xd/0x12
[ 202.937113] dump_header+0x52/0x2f8
[ 202.937115] ? ___ratelimit+0x169/0x220
[ 202.937118] oom_kill_process.cold+0x5b/0xe4
[ 202.937119] ? __percpu_counter_sum+0x96/0xb0
[ 202.937122] ? try_to_free_pages+0x371/0x400
[ 202.937125] ? oom_badness+0x13b/0x1c0
[ 202.937127] out_of_memory+0xa8/0x3f0
[ 202.937128] __alloc_frozen_pages_noprof+0x790/0xa60
[ 202.937131] __folio_alloc_noprof+0x1f/0x40
[ 202.937132] secretmem_fault+0x108/0x1c0
[ 202.937134] __do_fault+0x30/0xa0
[ 202.937136] handle_mm_fault+0x831/0xe10
[ 202.937138] exc_page_fault+0x135/0x3b0
[ 202.937140] ? doublefault_shim+0x150/0x150
[ 202.937141] handle_exception+0x130/0x130
[ 202.937143] EIP: 0x804d2a8
[ 202.937145] Code: 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 00 00 00 89 44 0f fc 75 0e c1 e9 02 <f3> ab 8b 44 24 04 8b 7c 24 0c c3 31 d2 29 fa 83 e2 0f 89 07 89 47
[ 202.937146] EAX: 5a5a5a5a EBX: 00000000 ECX: 02c49c00 EDX: 6106d000
[ 202.937148] ESI: 00000000 EDI: 62746000 EBP: bfc9b598 ESP: bfc9b52c
[ 202.937149] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010206
[ 202.937150] ? doublefault_shim+0x150/0x150
[ 202.937152] Mem-Info:
[ 203.033004] active_anon:76 inactive_anon:5407 isolated_anon:0
[ 203.033004] active_file:3587 inactive_file:1924 isolated_file:0
[ 203.033004] unevictable:229432 dirty:19 writeback:0
[ 203.033004] slab_reclaimable:1836 slab_unreclaimable:3150
[ 203.033004] mapped:215094 shmem:2040 pagetables:680
[ 203.033004] sec_pagetables:0 bounce:0
[ 203.033004] kernel_misc_reclaimable:0
[ 203.033004] free:7605 free_pcp:2490 free_cma:0
[ 203.055764] Node 0 active_anon:304kB inactive_anon:21628kB active_file:14308kB inactive_file:7692kB unevictable:917728kB isolated(anon):0kB isolated(file):0kB mapped:860376kB dirty:76kB writeback:0kB shmem:8160kB kernel_stack:992kB pagetables:2720kB sec_pagetables:0kB all_unreclaimable? yes Balloon:0kB gpu_active:0kB gpu_reclaim:0kB
[ 203.073182] DMA free:3444kB boost:0kB min:64kB low:80kB high:96kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:11732kB writepending:0kB zspages:0kB present:15992kB managed:15360kB mlocked:11732kB bounce:0kB free_pcp:124kB local_pcp:124kB free_cma:0kB
[ 203.090364] lowmem_reserve[]: 0 852 990 990
[ 203.093476] Normal free:3408kB boost:0kB min:3644kB low:4552kB high:5460kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:308kB inactive_file:276kB unevictable:834060kB writepending:28kB zspages:0kB present:890872kB managed:873360kB mlocked:830868kB bounce:0kB free_pcp:9184kB local_pcp:3192kB free_cma:0kB
[ 203.111774] lowmem_reserve[]: 0 0 1102 1102
[ 203.114773] DMA: 1*4kB (U) 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 0*128kB 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 0*4096kB = 3444kB
[ 203.122523] Normal: 182*4kB (UME) 34*8kB (UE) 22*16kB (UE) 5*32kB (UE) 6*64kB (UE) 1*128kB (E) 0*256kB 1*512kB (E) 1*1024kB (M) 0*2048kB 0*4096kB = 3560kB
[ 203.131052] 237037 total pagecache pages
[ 203.134049] 0 pages in swap cache
[ 203.136716] Free swap = 0kB
[ 203.139008] Total swap = 0kB
[ 203.141426] 262009 pages RAM
[ 203.143843] 35293 pages HighMem/MovableOnly
[ 203.146820] 4536 pages reserved
[ 203.149415] Out of memory: Killed process 588 (allocate_secret) total-vm:2048216kB, anon-rss:24kB, file-rss:842648kB, shmem-rss:0kB, UID:0 pgtables:1680kB oom_score_adj:0
Killed ./allocate_secret_i686 2000M
[0] https://lore.kernel.org/all/DK0QLG6P7LXQ.OUG1KJ75V4MW@linux.dev/
[1] https://lore.kernel.org/all/20260703-secretmem-highmem-v1-1-30d5ff944664@google.com/
---
Changes in v2:
- Instead of disabling CONFIG_SECRETMEM, just drop __GFP_HIGHMEM
- Link to v1: https://patch.msgid.link/20260703-secretmem-highmem-v1-1-30d5ff944664@google.com
---
mm/secretmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 4877c262cb1f6..d29865075b6ea 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -202,7 +202,7 @@ static struct file *secretmem_file_create(unsigned long flags)
if (IS_ERR(file))
goto err_free_inode;
- mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
+ mapping_set_gfp_mask(inode->i_mapping, GFP_USER);
mapping_set_unevictable(inode->i_mapping);
inode->i_op = &secretmem_iops;
---
base-commit: 6efb6baa4a240b06bcef6b83cfca04cd2bad6852
change-id: 20260703-secretmem-highmem-44eb42fda318
Best regards,
--
Brendan Jackman <jackmanb@google.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mm/secretmem: don't allow highmem folios
2026-07-17 9:48 [PATCH v2] mm/secretmem: don't allow highmem folios Brendan Jackman
@ 2026-07-17 12:03 ` David Hildenbrand (Arm)
2026-07-17 12:44 ` Lorenzo Stoakes (ARM)
2026-07-18 10:49 ` Mike Rapoport
2 siblings, 0 replies; 4+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-17 12:03 UTC (permalink / raw)
To: Brendan Jackman, Andrew Morton, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko
Cc: linux-mm, linux-kernel, brendan.jackman
On 7/17/26 11:48, Brendan Jackman wrote:
> secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls
> set_direct_map_invalid_noflush() without checking folio_test_highmem().
> This causes a warning and process crash (vibe-coded reproducer in Link
> below):
>
> Su[ 30.071284] ------------[ cut here ]------------
> ccessfully allocated and mapped 2097152000 bytes at 0x3a449000
> Populating memor[ 30.074614] CPA: called for zero pte. vaddr = 0 cpa->vaddr = 0
> y...
> [ 30.078636] WARNING: arch/x86/mm/pat/set_memory.c:1840 at __cpa_process_fault+0x34d/0x360, CPU#5: allocate_secret/570
> [ 30.084789] CPU: 5 UID: 0 PID: 570 Comm: allocate_secret Not tainted 7.1.0-14063-g4edcdefd4083-dirty #10 PREEMPTLAZY
> [ 30.090937] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> [ 30.097543] EIP: __cpa_process_fault+0x34d/0x360
> [ 30.100514] Code: ff ff 85 c0 0f 89 7d fe ff ff e9 3d fe ff ff 8b 03 8b 00 c7 04 24 c8 ff 64 c1 89 44 24 08 8b 45 e8 89 44 24 04 e8 53 7
> a 00 00 <0f> 0b c7 45 f0 f2 ff ff ff e9 fc fc ff ff 90 8d 74 26 00 55 25 00
> [ 30.110829] EAX: 00000000 EBX: f64afe98 ECX: 00000000 EDX: 00000000
> [ 30.114799] ESI: 00000000 EDI: f64afe98 EBP: f64afe04 ESP: f64afdcc
> [ 30.118785] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010246
> [ 30.123020] CR0: 80050033 CR2: 46c48ffc CR3: 038c8000 CR4: 00000690
> [ 30.127010] Call Trace:
> [ 30.129078] __change_page_attr_set_clr+0x5e7/0x870
> [ 30.132275] ? console_unlock+0x99/0x130
> [ 30.135069] ? irq_work_queue+0x36/0x70
> [ 30.137853] ? page_address+0xd3/0xf0
> [ 30.140421] set_direct_map_invalid_noflush+0x52/0x60
> [ 30.143782] secretmem_fault+0x128/0x210
> [ 30.146560] __do_fault+0x25/0x90
> [ 30.149053] handle_mm_fault+0x6d1/0xcb0
> [ 30.151759] exc_page_fault+0x135/0x3b0
> [ 30.154487] ? doublefault_shim+0x150/0x150
> [ 30.157416] handle_exception+0x130/0x130
> [ 30.160137] EIP: 0x804d29f
> [ 30.162307] Code: 89 54 08 e1 89 54 08 e5 89 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 0
> 0 00 00 <89> 44 0f fc 75 0e c1 e9 02 f3 ab 8b 44 24 04 8b 7c 24 0c c3 31 d2
> [ 30.172936] EAX: 5a5a5a5a EBX: 00000000 ECX: 0c800000 EDX: 3a449000
> [ 30.176927] ESI: 00000000 EDI: 3a449000 EBP: bfbbae18 ESP: bfbbadac
> [ 30.180897] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010246
> [ 30.185161] ? doublefault_shim+0x150/0x150
> [ 30.187979] ---[ end trace 0000000000000000 ]---
> Bus error (core dumped) ./allocate_secret_i686 2000M
>
> The equivalent bug was pointed out by a local Sashiko instance on
> https://lore.kernel.org/all/20260410151746.61150-3-kalyazin@amazon.com/
>
> This hasn't been reproduced it on older kernel versions but from code
> inspection the bug seems to go back to the original introduction in
> commit 1507f51255c9f ("mm: introduce memfd_secret system call to create
> "secret" memory areas"). If this configuration has always been broken,
> there's no need to worry too much about feature regression here.
>
> Nonetheless, instead of just completely disabling secretmem under
> !HIGHMEM, just drop __GFP_HIGHMEM. This means that now where you
> previously got a crash, instead you'll just see the secretmem process
> OOM.
>
> Could secretmem just support highmem by saying "this isn't in the direct
> map anyway" and bailing out before the set_direct_map_invalid_noflush()?
> Maybe. That depends on requirements that are not well-defined (e.g. is
> it OK that kmap_local_page() is not a NOP for those pages?), and would
> require some research and deep thinking. Let's "defer" that until
> an actual usecase arises.
>
> Link: https://github.com/bjackman/limmat-kernel-nix/commit/7b2acba2d3a5ef01400d493a155beb1d135b6bb5
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org/
> Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> Based on mm-new with `[PATCH] mm/secretmem: disable under HIGHMEM` [1]
> reverted.
>
> Note this was found by Sashiko but in a local instance, so I can't
> provide a link to the report and I guess it's technically inaccurate to
> mention sashiko-bot@kernel.org.
We sometimes just used Reported-by: Sashiko ...without a link report.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mm/secretmem: don't allow highmem folios
2026-07-17 9:48 [PATCH v2] mm/secretmem: don't allow highmem folios Brendan Jackman
2026-07-17 12:03 ` David Hildenbrand (Arm)
@ 2026-07-17 12:44 ` Lorenzo Stoakes (ARM)
2026-07-18 10:49 ` Mike Rapoport
2 siblings, 0 replies; 4+ messages in thread
From: Lorenzo Stoakes (ARM) @ 2026-07-17 12:44 UTC (permalink / raw)
To: Brendan Jackman
Cc: Andrew Morton, David Hildenbrand, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
linux-mm, linux-kernel, brendan.jackman
On Fri, Jul 17, 2026 at 09:48:59AM +0000, Brendan Jackman wrote:
> secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls
> set_direct_map_invalid_noflush() without checking folio_test_highmem().
> This causes a warning and process crash (vibe-coded reproducer in Link
> below):
>
> Su[ 30.071284] ------------[ cut here ]------------
> ccessfully allocated and mapped 2097152000 bytes at 0x3a449000
> Populating memor[ 30.074614] CPA: called for zero pte. vaddr = 0 cpa->vaddr = 0
> y...
> [ 30.078636] WARNING: arch/x86/mm/pat/set_memory.c:1840 at __cpa_process_fault+0x34d/0x360, CPU#5: allocate_secret/570
> [ 30.084789] CPU: 5 UID: 0 PID: 570 Comm: allocate_secret Not tainted 7.1.0-14063-g4edcdefd4083-dirty #10 PREEMPTLAZY
> [ 30.090937] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> [ 30.097543] EIP: __cpa_process_fault+0x34d/0x360
> [ 30.100514] Code: ff ff 85 c0 0f 89 7d fe ff ff e9 3d fe ff ff 8b 03 8b 00 c7 04 24 c8 ff 64 c1 89 44 24 08 8b 45 e8 89 44 24 04 e8 53 7
> a 00 00 <0f> 0b c7 45 f0 f2 ff ff ff e9 fc fc ff ff 90 8d 74 26 00 55 25 00
> [ 30.110829] EAX: 00000000 EBX: f64afe98 ECX: 00000000 EDX: 00000000
> [ 30.114799] ESI: 00000000 EDI: f64afe98 EBP: f64afe04 ESP: f64afdcc
> [ 30.118785] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010246
> [ 30.123020] CR0: 80050033 CR2: 46c48ffc CR3: 038c8000 CR4: 00000690
> [ 30.127010] Call Trace:
> [ 30.129078] __change_page_attr_set_clr+0x5e7/0x870
> [ 30.132275] ? console_unlock+0x99/0x130
> [ 30.135069] ? irq_work_queue+0x36/0x70
> [ 30.137853] ? page_address+0xd3/0xf0
> [ 30.140421] set_direct_map_invalid_noflush+0x52/0x60
> [ 30.143782] secretmem_fault+0x128/0x210
> [ 30.146560] __do_fault+0x25/0x90
> [ 30.149053] handle_mm_fault+0x6d1/0xcb0
> [ 30.151759] exc_page_fault+0x135/0x3b0
> [ 30.154487] ? doublefault_shim+0x150/0x150
> [ 30.157416] handle_exception+0x130/0x130
> [ 30.160137] EIP: 0x804d29f
> [ 30.162307] Code: 89 54 08 e1 89 54 08 e5 89 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 0
> 0 00 00 <89> 44 0f fc 75 0e c1 e9 02 f3 ab 8b 44 24 04 8b 7c 24 0c c3 31 d2
> [ 30.172936] EAX: 5a5a5a5a EBX: 00000000 ECX: 0c800000 EDX: 3a449000
> [ 30.176927] ESI: 00000000 EDI: 3a449000 EBP: bfbbae18 ESP: bfbbadac
> [ 30.180897] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010246
> [ 30.185161] ? doublefault_shim+0x150/0x150
> [ 30.187979] ---[ end trace 0000000000000000 ]---
> Bus error (core dumped) ./allocate_secret_i686 2000M
>
> The equivalent bug was pointed out by a local Sashiko instance on
> https://lore.kernel.org/all/20260410151746.61150-3-kalyazin@amazon.com/
>
> This hasn't been reproduced it on older kernel versions but from code
> inspection the bug seems to go back to the original introduction in
> commit 1507f51255c9f ("mm: introduce memfd_secret system call to create
> "secret" memory areas"). If this configuration has always been broken,
> there's no need to worry too much about feature regression here.
>
> Nonetheless, instead of just completely disabling secretmem under
> !HIGHMEM, just drop __GFP_HIGHMEM. This means that now where you
> previously got a crash, instead you'll just see the secretmem process
> OOM.
>
> Could secretmem just support highmem by saying "this isn't in the direct
> map anyway" and bailing out before the set_direct_map_invalid_noflush()?
> Maybe. That depends on requirements that are not well-defined (e.g. is
> it OK that kmap_local_page() is not a NOP for those pages?), and would
> require some research and deep thinking. Let's "defer" that until
> an actual usecase arises.
I mean, I vote let's get rid of highmem altogether ;)
>
> Link: https://github.com/bjackman/limmat-kernel-nix/commit/7b2acba2d3a5ef01400d493a155beb1d135b6bb5
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org/
> Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
LGTM, so:
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> Based on mm-new with `[PATCH] mm/secretmem: disable under HIGHMEM` [1]
> reverted.
>
> Note this was found by Sashiko but in a local instance, so I can't
> provide a link to the report and I guess it's technically inaccurate to
> mention sashiko-bot@kernel.org.
>
> I wrote in [0] that I needed to compile a 32bit OS but I was wrong, the
> build is already done and this is tested on QEMU, the vibe-coded repro
> linked in the patch now gets OOM-killed as appropriate:
>
> Populated 838860800/2097152000 bytes (40%)...
> [ 202.930157] allocate_secret invoked oom-killer: gfp_mask=0x140dc0(GFP_USER|__GFP_ZERO|__GFP_COMP), order=0, oom_score_adj=0
> [ 202.937102] CPU: 1 UID: 0 PID: 588 Comm: allocate_secret Not tainted 7.2.0-rc2-00579-g00ba42d1257f #56 PREEMPTLAZY
> [ 202.937105] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> [ 202.937106] Call Trace:
> [ 202.937108] dump_stack_lvl+0x44/0x64
> [ 202.937112] dump_stack+0xd/0x12
> [ 202.937113] dump_header+0x52/0x2f8
> [ 202.937115] ? ___ratelimit+0x169/0x220
> [ 202.937118] oom_kill_process.cold+0x5b/0xe4
> [ 202.937119] ? __percpu_counter_sum+0x96/0xb0
> [ 202.937122] ? try_to_free_pages+0x371/0x400
> [ 202.937125] ? oom_badness+0x13b/0x1c0
> [ 202.937127] out_of_memory+0xa8/0x3f0
> [ 202.937128] __alloc_frozen_pages_noprof+0x790/0xa60
> [ 202.937131] __folio_alloc_noprof+0x1f/0x40
> [ 202.937132] secretmem_fault+0x108/0x1c0
> [ 202.937134] __do_fault+0x30/0xa0
> [ 202.937136] handle_mm_fault+0x831/0xe10
> [ 202.937138] exc_page_fault+0x135/0x3b0
> [ 202.937140] ? doublefault_shim+0x150/0x150
> [ 202.937141] handle_exception+0x130/0x130
> [ 202.937143] EIP: 0x804d2a8
> [ 202.937145] Code: 54 08 e9 89 54 08 ed c3 0f b6 44 24 08 89 7c 24 0c 69 c0 01 01 01 01 8b 7c 24 04 f7 c7 0f 00 00 00 89 44 0f fc 75 0e c1 e9 02 <f3> ab 8b 44 24 04 8b 7c 24 0c c3 31 d2 29 fa 83 e2 0f 89 07 89 47
> [ 202.937146] EAX: 5a5a5a5a EBX: 00000000 ECX: 02c49c00 EDX: 6106d000
> [ 202.937148] ESI: 00000000 EDI: 62746000 EBP: bfc9b598 ESP: bfc9b52c
> [ 202.937149] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00010206
> [ 202.937150] ? doublefault_shim+0x150/0x150
> [ 202.937152] Mem-Info:
> [ 203.033004] active_anon:76 inactive_anon:5407 isolated_anon:0
> [ 203.033004] active_file:3587 inactive_file:1924 isolated_file:0
> [ 203.033004] unevictable:229432 dirty:19 writeback:0
> [ 203.033004] slab_reclaimable:1836 slab_unreclaimable:3150
> [ 203.033004] mapped:215094 shmem:2040 pagetables:680
> [ 203.033004] sec_pagetables:0 bounce:0
> [ 203.033004] kernel_misc_reclaimable:0
> [ 203.033004] free:7605 free_pcp:2490 free_cma:0
> [ 203.055764] Node 0 active_anon:304kB inactive_anon:21628kB active_file:14308kB inactive_file:7692kB unevictable:917728kB isolated(anon):0kB isolated(file):0kB mapped:860376kB dirty:76kB writeback:0kB shmem:8160kB kernel_stack:992kB pagetables:2720kB sec_pagetables:0kB all_unreclaimable? yes Balloon:0kB gpu_active:0kB gpu_reclaim:0kB
> [ 203.073182] DMA free:3444kB boost:0kB min:64kB low:80kB high:96kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:11732kB writepending:0kB zspages:0kB present:15992kB managed:15360kB mlocked:11732kB bounce:0kB free_pcp:124kB local_pcp:124kB free_cma:0kB
> [ 203.090364] lowmem_reserve[]: 0 852 990 990
> [ 203.093476] Normal free:3408kB boost:0kB min:3644kB low:4552kB high:5460kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:308kB inactive_file:276kB unevictable:834060kB writepending:28kB zspages:0kB present:890872kB managed:873360kB mlocked:830868kB bounce:0kB free_pcp:9184kB local_pcp:3192kB free_cma:0kB
> [ 203.111774] lowmem_reserve[]: 0 0 1102 1102
> [ 203.114773] DMA: 1*4kB (U) 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 0*128kB 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 0*4096kB = 3444kB
> [ 203.122523] Normal: 182*4kB (UME) 34*8kB (UE) 22*16kB (UE) 5*32kB (UE) 6*64kB (UE) 1*128kB (E) 0*256kB 1*512kB (E) 1*1024kB (M) 0*2048kB 0*4096kB = 3560kB
> [ 203.131052] 237037 total pagecache pages
> [ 203.134049] 0 pages in swap cache
> [ 203.136716] Free swap = 0kB
> [ 203.139008] Total swap = 0kB
> [ 203.141426] 262009 pages RAM
> [ 203.143843] 35293 pages HighMem/MovableOnly
> [ 203.146820] 4536 pages reserved
> [ 203.149415] Out of memory: Killed process 588 (allocate_secret) total-vm:2048216kB, anon-rss:24kB, file-rss:842648kB, shmem-rss:0kB, UID:0 pgtables:1680kB oom_score_adj:0
> Killed ./allocate_secret_i686 2000M
>
> [0] https://lore.kernel.org/all/DK0QLG6P7LXQ.OUG1KJ75V4MW@linux.dev/
> [1] https://lore.kernel.org/all/20260703-secretmem-highmem-v1-1-30d5ff944664@google.com/
> ---
> Changes in v2:
> - Instead of disabling CONFIG_SECRETMEM, just drop __GFP_HIGHMEM
> - Link to v1: https://patch.msgid.link/20260703-secretmem-highmem-v1-1-30d5ff944664@google.com
> ---
> mm/secretmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index 4877c262cb1f6..d29865075b6ea 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -202,7 +202,7 @@ static struct file *secretmem_file_create(unsigned long flags)
> if (IS_ERR(file))
> goto err_free_inode;
>
> - mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
> + mapping_set_gfp_mask(inode->i_mapping, GFP_USER);
> mapping_set_unevictable(inode->i_mapping);
>
> inode->i_op = &secretmem_iops;
>
> ---
> base-commit: 6efb6baa4a240b06bcef6b83cfca04cd2bad6852
> change-id: 20260703-secretmem-highmem-44eb42fda318
>
> Best regards,
> --
> Brendan Jackman <jackmanb@google.com>
>
Cheers, Lorenzo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] mm/secretmem: don't allow highmem folios
2026-07-17 9:48 [PATCH v2] mm/secretmem: don't allow highmem folios Brendan Jackman
2026-07-17 12:03 ` David Hildenbrand (Arm)
2026-07-17 12:44 ` Lorenzo Stoakes (ARM)
@ 2026-07-18 10:49 ` Mike Rapoport
2 siblings, 0 replies; 4+ messages in thread
From: Mike Rapoport @ 2026-07-18 10:49 UTC (permalink / raw)
To: Brendan Jackman
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, linux-mm, linux-kernel, brendan.jackman
On Fri, Jul 17, 2026 at 09:48:59AM +0000, Brendan Jackman wrote:
> secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls
> set_direct_map_invalid_noflush() without checking folio_test_highmem().
> This causes a warning and process crash (vibe-coded reproducer in Link
> below):
...
> Link: https://github.com/bjackman/limmat-kernel-nix/commit/7b2acba2d3a5ef01400d493a155beb1d135b6bb5
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org/
> Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "secret" memory areas")
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-07-18 10:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-07-17 9:48 [PATCH v2] mm/secretmem: don't allow highmem folios Brendan Jackman
2026-07-17 12:03 ` David Hildenbrand (Arm)
2026-07-17 12:44 ` Lorenzo Stoakes (ARM)
2026-07-18 10:49 ` Mike Rapoport
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome