From nobody Sat Jul 25 05:29:26 2026 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31F8B3E5A13 for ; Fri, 17 Jul 2026 09:49:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784281755; cv=none; b=DA5zrRVq4RZhJR2DqsFR2/FAgT/bX/6M95JYiqzdjN0XVOTbjGc4DjEe/yjcetNo7IDIbB9taUSFVnPM9J4gigm7Yswm31tUhwYJx9qLhQJSYxixpSz9B0LBj0s2k5vdi1E7cS5odyyjT1BzBgAzkpOlHL3NA+lZg5iYBnLosO0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784281755; c=relaxed/simple; bh=ogDRMrg1liQ94uaY2T3i+wcTSXM+c0nayHTpft4dHko=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=ETQMDa5n8K5wf1+sECKjWYK/yZWsyt/BjAmfylzlI4IA0K9NHTcqcPd4ghR795UCjt6hpubHfBYcflvZs/qqTHmu1tO6ouCOK35a7bduZ0EXCP/xMO+ViMR5wNvhMaT8KP9mt5D+X9hgm5LQtUDcUi3qlchjwgLz6cDDnKvkzJI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Q2E9An6O; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Q2E9An6O" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-4953c5d6d87so29844575e9.3 for ; Fri, 17 Jul 2026 02:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784281750; x=1784886550; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:from:to:cc:subject:date:message-id :reply-to:content-type; bh=b3usD1jJxI3pzSp/aKzJE2Bfrpprk+w/Fy/6jAyUXeA=; b=Q2E9An6OMYdxAXJZnGvLiH1qRgLkgE7xIBgxTrpI16OWsbVFO2AQCY709O9J4mlDNx eLgrzjjUYFpQzqqo71c0HPhtlGYedvin9E25rY8eMtW9RmGA0bs098t/qpadU6BLVU5E yOpIv7xJUaOmOqsLyV7J2yWFJDLjHuVV2oYvK/r0GeObFP0d4KlSHu88DQGAMb8BUMHJ O7csAOxuIAzppd5BpHg0Tmq72yvNOlk1gNi3Qb/bIV2JZEDmqUFs4kjTO/X/oLywAgCO SZMYjqPuqJBoB1LlHeq3s56HNBlCV9br7D7H2JrIk14BOZ2zN7iOwLfWZNB5n0faG650 vcMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784281750; x=1784886550; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=b3usD1jJxI3pzSp/aKzJE2Bfrpprk+w/Fy/6jAyUXeA=; b=ePAF9A50GNFngGXEuT5pD+xq7c5OVQxb5NYf6GhILsxFn3ksk/1JbUIZvXnBZa+yzg V42bjWHmnZ8V2WCNyZNRfQvgwCJux7OpAPOoBMyUhtxofq5hmEE6p6IGfpLEy4jL/wM2 MMQCx3/Jkr5BwmDXRmLGMG4Y6OFCSzfFOGJ3dI/1ZFpM2q/8qoOC0qD4Wz4T+Q92A1RO ySb4BO5kSoT5pWvv0kkOVsJPFjiRLJpIm272Dd44HXeOMOLYhr1MDmJZMPkmlYWprYS3 69iClrjAyyhwY3QTRX3vFVyG0l8F2uKciO29Qa2B4uA0nmsUJLwQ/IhiFdudHEvRqTqj 2Ltg== X-Forwarded-Encrypted: i=1; AHgh+Rrkgg6cvBXYSH71mZ2sTQ4HAWAHqkb0Ez/H6Nyrc86L10KlvzqkxNTs+QXUY1ojN/u3BcgrGn2Qw7zt51Q=@vger.kernel.org X-Gm-Message-State: AOJu0YzUPYXs77Oh2eMiHhrJ57gOyXYUdtvkXh66AWrnM6iVr+sUvWgF CEcHrf+TiJgOJ+ErMLNfDgc21TSgDGvDFqtYybSDp1OB5GfxpU1ZaKpDhPd8K4VHZcjXfbXlggU IEKXz2tdOGYZ1xw== X-Received: from wmjs18.prod.google.com ([2002:a7b:c392:0:b0:493:bb90:757f]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:6a0b:b0:493:c453:6002 with SMTP id 5b1f17b1804b1-4954a516453mr13238255e9.35.1784281749393; Fri, 17 Jul 2026 02:49:09 -0700 (PDT) Date: Fri, 17 Jul 2026 09:48:59 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAIr6WWoC/32Nyw6CMBREf4XctTV9iY+V/2FYQLltrxFqWiQaw r/b4t7V5CQzZxZIGAkTXKoFIs6UKIwZ5K4C49vRIaM+M0gua37kiiU0EacBB+bJ+ZJaY6el7Vs lTpB3z4iW3pvz1vw4vbo7mqmISsNTmkL8bKezKL1//lkwwRTvD9aeta5rfXUhuAfuTRigWdf1C ysvVm3FAAAA X-Change-Id: 20260703-secretmem-highmem-44eb42fda318 X-Mailer: b4 0.15.2 Message-ID: <20260717-secretmem-highmem-v2-1-1f1a961ca91e@google.com> Subject: [PATCH v2] mm/secretmem: don't allow highmem folios From: Brendan Jackman To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, brendan.jackman@linux.dev, Brendan Jackman Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =3D 0 cpa->v= addr =3D 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/7b2acba2d3a5ef01= 400d493a155beb1d135b6bb5 Suggested-by: Andrew Morton Link: https://lore.kernel.org/all/20260704192603.40aa80cf9242b77aa75e8d8d@l= inux-foundation.org/ Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "se= cret" memory areas") Signed-off-by: Brendan Jackman Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes (ARM) Reviewed-by: Mike Rapoport (Microsoft) --- 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=3D0x140dc0(GFP_= USER|__GFP_ZERO|__GFP_COMP), order=3D0, oom_score_adj=3D0 [ 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 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:1= 4308kB inactive_file:7692kB unevictable:917728kB isolated(anon):0kB isolate= d(file):0kB mapped:860376kB dirty:76kB writeback:0kB shmem:8160kB kernel_st= ack:992kB pagetables:2720kB sec_pagetables:0kB all_unreclaimable? yes Ballo= on:0kB gpu_active:0kB gpu_reclaim:0kB [ 203.073182] DMA free:3444kB boost:0kB min:64kB low:80kB high:96kB reserv= ed_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB act= ive_file:0kB inactive_file:0kB unevictable:11732kB writepending:0kB zspages= :0kB present:15992kB managed:15360kB mlocked:11732kB bounce:0kB free_pcp:12= 4kB 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:5460= kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_ano= n:0kB active_file:308kB inactive_file:276kB unevictable:834060kB writependi= ng:28kB zspages:0kB present:890872kB managed:873360kB mlocked:830868kB boun= ce: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*128k= B 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 0*4096kB =3D 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 = =3D 3560kB [ 203.131052] 237037 total pagecache pages [ 203.134049] 0 pages in swap cache [ 203.136716] Free swap =3D 0kB [ 203.139008] Total swap =3D 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-30d5ff94466= 4@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-30d5= ff944664@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; =20 - mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); + mapping_set_gfp_mask(inode->i_mapping, GFP_USER); mapping_set_unevictable(inode->i_mapping); =20 inode->i_op =3D &secretmem_iops; --- base-commit: 6efb6baa4a240b06bcef6b83cfca04cd2bad6852 change-id: 20260703-secretmem-highmem-44eb42fda318 Best regards, -- =20 Brendan Jackman