From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (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 B4A3D3D5C12 for ; Fri, 3 Jul 2026 14:48:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783090115; cv=none; b=Kn2Yfl4gWo1qLQG85M6Datk1d5UcCYmDczWAmmNM9F80HPMUgEyn9APYd18FBz99CDi6QZmcb5NpFwylyZm5Zp7WWYIjsaeGgA2Gmu0pjTKMaQ9D56oWm12uONXk3xQ43xk/NBTgdmxvrabR5N7sqqX2zy1EnrJZp7iWbaBc/Xc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783090115; c=relaxed/simple; bh=1zQakWheA1XFrLLAxL3eRyh6RvPoK0v2k37/UQucE6k=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=rCKTe7dh3Qs0emEExZ8B5J6VqZFGsIPXeP09IE+XY0vkyErSIqnmx/88ra4ED5Q84fnRWF8JhhugxAYE4B4ExNqxZU2/9tv0wi8w5khEIWPkzM1rkry+sHZDDL3cY70joXLpkvLFXE75ygSEf6vmLljaxidijGSGU7pwUWZjVA8= 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=Y9R/cHKw; arc=none smtp.client-ip=209.85.128.73 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="Y9R/cHKw" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-493a7fa8481so12944195e9.1 for ; Fri, 03 Jul 2026 07:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783090112; x=1783694912; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=FA+aJY22ICn5BB3vWx6DuJp5j1iC2aa98uELpr+1DAY=; b=Y9R/cHKw4LQTEs7Q0YIKqMCaLZ6Tt26cuBe6rOEChU1Jo4WBsNo6EPvgn+IBTwFR7E SGln1XEse6lh4hOvUBcXrh6mxOWhECOLfmRl3UrSXkcscl8AN/6/8vgoHI83rjiQv/VH vJksNmbnr1k9tRPWwpDRLrh3nwhLfbOcwD9DGWkeHtOjmwrcfRVvtegpXsfjkTiPXzvQ nevHXTRtnHVFz3tuQ/2WlrlfCKqBDO1Opm8IY3LzMuC9kNqKmmObUXvpl2ueUQtlsI0B Q7EIr0aDH+otOaSxmv8jWDC3kq1/+JChwuGvjSPl5LoJeGNT9E1GBxWeQdYycv8x9ZZb MP6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783090112; x=1783694912; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FA+aJY22ICn5BB3vWx6DuJp5j1iC2aa98uELpr+1DAY=; b=L6OkL1L22RDrma8ws/trDCEesL9g7dNQea7xKKVCB33OthNuEy6O9FTbWEsUZkerIV 8nHNJn+qhLj1HA+efTUwY2d4JNIYr7b9OIADgkiUcIkwCJSlB0Vwgan1eq0kDmNxKb25 Sd/2cCPNUpAYG7TMnMpx1p8gcfGKyEHAmrPd7fhnVcGy3VAO27xacxlO9SMvd+EWZ3QM q8/H95glMVhCCrB4JqlRhFjcRviT8C/Xlk5zozcLO8PrNNLgaDKGMTKaXKP4etMW8Eh5 A4KZ3C7SLQnTjmE4zhztbsLf5HoUobxvGVgHXyPOt3MqA0v7/74vwc56d9I25NSW39yv +FkA== X-Forwarded-Encrypted: i=1; AFNElJ8ScptpxrF4T0vTPmocBPNHrAm2WAd0rO5u0Cc07pzrIR/nqUlP/vGXKZldFvWErrokZ6gNi7II+laZK98=@vger.kernel.org X-Gm-Message-State: AOJu0YxVmZ9YxfzipuMbplb/sY/M8+rN0X5GS90GfnQY9IMga8PIKHLh thV55xwLNIY4HDeV9PZ4yFgc2sKkADLi9KbCzYiqON4ggMplnPV4/ICAhV0E4OVqYL4hG94nOr3 k6Oi7Kp3I2U+EgQ== X-Received: from wmbhb6.prod.google.com ([2002:a05:600c:8686:b0:493:b080:8b95]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600d:4448:20b0:492:3fb5:3a17 with SMTP id 5b1f17b1804b1-493c9b44882mr44220215e9.2.1783090111878; Fri, 03 Jul 2026 07:48:31 -0700 (PDT) Date: Fri, 03 Jul 2026 14:48:26 +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=H4sIALnLR2oC/yXMwQqDMBCE4VeRPTcQY1Dpq0gPmkzMClrJ2iKI7 25sT8N3mP8gQWIIPYuDEr4s/F4yykdBLvbLCMU+m4w2tW50pQQuYZsxq8hjvNdaDNYE31dlS/m 3JgTef83u9bd8hgluu0N0nhfpboN9dQAAAA== X-Change-Id: 20260703-secretmem-highmem-44eb42fda318 X-Mailer: b4 0.16-dev Message-ID: <20260703-secretmem-highmem-v1-1-30d5ff944664@google.com> Subject: [PATCH] mm/secretmem: disable under HIGHMEM 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 Content-Type: text/plain; charset="utf-8" secretmem_fault() allocates a folio with GFP_HIGHUSER and then calls set_direct_map_valid_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, dropping support is not really a regression, so do that. Link: https://github.com/bjackman/limmat-kernel-nix/commit/7b2acba2d3a5ef01400d493a155beb1d135b6bb5 Fixes: 1507f51255c9f ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Brendan Jackman --- 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. --- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 04fe5171bb8c8..17c3b77b21a6a 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1356,7 +1356,7 @@ config MEMFD_CREATE config SECRETMEM default y bool "Enable memfd_secret() system call" if EXPERT - depends on ARCH_HAS_SET_DIRECT_MAP + depends on ARCH_HAS_SET_DIRECT_MAP && !HIGHMEM help Enable the memfd_secret() system call with the ability to create memory areas visible only in the context of the owning process and --- base-commit: 0efcf9df728408cdc9f78868f1753ec0c5319f7c change-id: 20260703-secretmem-highmem-44eb42fda318 Best regards, -- Brendan Jackman