From patchwork Wed Apr 9 20:03:16 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jann Horn X-Patchwork-Id: 14045487 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9973CC36002 for ; Wed, 9 Apr 2025 20:03:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FB316B01A7; Wed, 9 Apr 2025 16:03:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AA916B01A8; Wed, 9 Apr 2025 16:03:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04CDF6B01AA; Wed, 9 Apr 2025 16:03:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D88816B01A7 for ; Wed, 9 Apr 2025 16:03:26 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8690FAF751 for ; Wed, 9 Apr 2025 20:03:27 +0000 (UTC) X-FDA: 83315580054.02.85F7BC3 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf09.hostedemail.com (Postfix) with ESMTP id B0138140008 for ; Wed, 9 Apr 2025 20:03:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mu+jM9gh; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744229005; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=ibP2CU6RAFJSeqUSlrkOvkOcHxqYPK+98gOWakQDC6c=; b=r2lnx+sRkkN5dbOtjYM4ouKec207MR02XNn6soktOu+HDckYMZ3Y4D9Xu6jT8xFQm9mfZp Ku6r39kMXLCJVATJ5K9PvPoYXRqG9cpQ+aWdcWPyue5JIjf+Oot+eMqmkqF2KlGrGn9PBG yWLxx3IV806Hv8tDeUMKIHdFbspmpEU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mu+jM9gh; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744229005; a=rsa-sha256; cv=none; b=1QHnBGeoMr14sqzAoEirgCCiOYx7LEP4xf54Dy4wEKScAcP8GVVBp8PiXcqjnIza48RXQ+ vwS83AIXjIFm/ESPsRJuN+keWhD/Jn5vPbzvkkhtsRhy1I34VkkB7WQNZsu0zN64SG9OpH QtojAHbTc26TPt1F/sDdORwc9mllE30= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-43ef83a6bfaso1495e9.1 for ; Wed, 09 Apr 2025 13:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744229004; x=1744833804; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ibP2CU6RAFJSeqUSlrkOvkOcHxqYPK+98gOWakQDC6c=; b=Mu+jM9ghRrKKDbjb78hJ0/NZF3sAQUCed33rxjMCc9lYTXUa0kNbuDy1gNmWgNHUA8 hKwhE7h0KJ4mfYV91p2x1Ccx0gSplGbL+PhTQg0obKJTzayNLUAzVD8L94wT9lWjagbM bpyH5Qjg1+C71+Pjrlh7ikNbn4s7+NkjY+5QbOpcUhPYDe0Y0Qs8aoLhYoAVAErFdod3 EeJzUT09RQXuBW2JWofNHqXRoax0Ni6GKgJuT7EnwgDNSgnXzGjsOhdNAlgH39Ex+v+F m6mcSIb0CZAPsd2D/VrBQZaggF1QEzmVYYOnTu1cVZgROpwAD/WOeg9WSMJM5B1D2b1/ Pvqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744229004; x=1744833804; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ibP2CU6RAFJSeqUSlrkOvkOcHxqYPK+98gOWakQDC6c=; b=e6wYVEJKu2SPpMBGgPHxR1RhJtlcy6Ust3COzhf3WY9tXPskzmT9g6r9OOzg1csmFW W/pum0OTg86uXfVYJhzqvsVmlbHpH2Nz1//sG+LnPwvCMyjl6nqFhqPf2XhKRA8l+7jx tkbPm9LuXoLDzllklzuVxJ3vpVj8lQgGrVcjV3QxaHusbnMNhqN4FzUfuTJUYX+LQuVk /wrG74HYGMEOr6TtXhGcuvRDZXmjg9moMm/bmuV5ufytJNQ/T1tBGJxZq/nFscmT+qF+ wdJPxG9vZ/Ws3TS5sotLeQ5AbiDPy1ZR2/r/kBCJaXERro2/eAeJZ1jnRdodsRdtaHIO 0zYA== X-Forwarded-Encrypted: i=1; AJvYcCXPw+w3EpS3r11tB0dSG0SN9Jh60adrMt8hen72vCoE2lkM2V8yEyCEtWhI9O+8iGMJZCMCH48lvQ==@kvack.org X-Gm-Message-State: AOJu0YydNNJRds0vn6KB/Wy0PVFefDD+n6k9dUKGgbOv3DZJjNfKv81q CRcUVZWo1GMQkbLHgSaRijgHLxdf0n3AdVWbj48VSRuJF9qF/xy11dDpguNKKg== X-Gm-Gg: ASbGncvIPpL01lzXSkeYSRbWGDvDMUuWNm6xKCM2PHnErys2sEZ8qKtrPw8v+LZHCxb y216FSOZ8BUUCMh0spvCt9kSwhA3ROXxQFagVmU3WrF/fYa+FIKuebMR5pDfGqn95xfFEMSf0Ho zsLPCJxCxwVlKSvhWwyXH3I5B4rebDBHSJcA2/s1ZCs5Z/IP5YNsDOPbxdTBv5aKQ6L5ePUILOF fWFodaGa/J3IABWE0VpbA9C2ZAYAgqEAdUwbrUXMYC55slBnVUofilZQ0FXfl9oMhp0gUvhkugj VhigKSjP7gCTvqtruuAsy5+D46yI+A== X-Google-Smtp-Source: AGHT+IG6niI2hvwR6UeodCm2LxQ33raWiJJ1zWlTTycqnhO+IaVHjMAPiCodW4wIumoymwLCneEXbw== X-Received: by 2002:a05:600c:3b09:b0:43b:bf3f:9664 with SMTP id 5b1f17b1804b1-43f2e2df5a2mr114045e9.5.1744229003612; Wed, 09 Apr 2025 13:03:23 -0700 (PDT) Received: from localhost ([2a00:79e0:9d:4:3a4a:b867:2c16:399f]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-43f2338d757sm26436995e9.5.2025.04.09.13.03.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 13:03:22 -0700 (PDT) From: Jann Horn To: Alejandro Colomar Cc: linux-man@vger.kernel.org, Andrew Morton , "Liam R . Howlett" , Lorenzo Stoakes , Vlastimil Babka , linux-mm@kvack.org Subject: [PATCH man] mmap.2: Document danger of mappings larger than PTRDIFF_MAX Date: Wed, 9 Apr 2025 22:03:16 +0200 Message-ID: <20250409200316.1555164-1-jannh@google.com> X-Mailer: git-send-email 2.49.0.504.g3bcea36a83-goog MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B0138140008 X-Stat-Signature: epmhongtgdp8essquqq1u1d4jtd4gf6w X-HE-Tag: 1744229005-6107 X-HE-Meta: U2FsdGVkX1/VeU48ejqvpD5teipbF68pP10F9BW+3uyLxRdatAJ/ETeJRfZcDzN/3Mb0JcptL02e8SMbSlnXmvEg5a2WDK5wGmoxOOihGSsGveSHs+59S7Ep3XZNT1A8dP0Oar4M9OMkGMeYDRJga217PBJkXe67VIWU9tfKcMZ6pAnTBb3XjTtkrMFfLV77+jaqTE3sNVyidFOUmC+Dc0RUvUul+uytd1DDF1/+8+AHva2Sd9yRHIHhJrIB1kUNHBvlfOO/nAeDS9MJk6oN2ssUix12bl0IFoML0rKI/OfYUvXPBXf88sbpRdAxx71g8AnOAQdL36RVrfWxWI2ed9pquo5ar8GLyVZsXE+wPWsYreEs46fEvkKF1IwnCMW7I+btPiA+QzcDgTFMey9U6Yh/Vl6lFr+G6qDfOvv6+nzRJThSfmtLY1L8EdE1D8z/MCEBau3vSB84PAzxzaoFC58KXIfo1SX05V8WoSOev1NazFLMshb9raQXIuvYdMrFvrikHomnz80N7ukw7YlFLEQlnXggZyllcNNxeQCx2UiLM5L2RVrsQJF4t2WERgAqiO8BkFqyiGJp0fsHvaGmf7TIMf9sRnzVEnvlpZjRawOD0shLD9QUb2JVqGhFFQJlVrbmQ3GelBqk5+v0Jax8/rP+qwlDDhutFfNbmwYMFXXMhSqdLOqAfJxFsdXSe+0+AUCbcxlDHKaxlg4Po6rMpyTlFIBCX66GGTJxZjiBwxlz+hJvR5Z57z8TA0j9BWGehhhR/wv5ZG7HA2abzyrjclJ06+c9/HBngpL9gq/nQ6Ray8WQdlONV9HHKCB31h9QniS5zQgKEslbnjpFdqX1a5EeGGXpXIcnjQnGokP6QcH1gpzCvJPI0OgxYDOzxf8bfDsRshWzwgmKlzmvU1CJCoJLbqC5sNK2e3duLqwBft0cx2TjwO95fhm/iwhA4Y1vRG9zpen2896FAMqPk7S u1MLFL64 tcf9u6pDyiBRiKtJbalyHx5ZoXDf0k983C6hj6bU9OMl5bNQmQuJPUoLelafYfH3/jWCHUGVXyel/LNj5z2i8I8aJNZPraAEhJ+wNTxUm6kXfoOWjuOyAZV1TMKh22p0/Imowjq6tDPpBdRacc+oSNzuqp/zwg8PdX3X1r7LBUeTrRjKRdfw9d2vVfEtww8B5gpprM9GytUInJvXg5JtJGbh7MqmMqYGrPd4Tj25xfrI/ZtN75TOy5xUq0jE+1g65VFu6RgM9+i39BjcBsuvQC7StMxvlRS9C3n3AZjwcbHJAP8vxUXtr4zgISq0jCNWElq/txEdafsSbT4JCvuDJ+JdpRA1UP3Vt78iPDFiZR8M4F1kHyE9xXmm7mkxgX82dVQG0pDiV0BAbrEO9Utl9Uqg5MgtuJLr3l2z9dKLXHjQXtERnhLeUTG0Ovcq66V9sRKonsvhY0eJUGbEz+56WK+OQJTuLTooAnz10P/g7qdoFyqc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.223302, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: References: - C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section "6.5.6 Additive operators", paragraph 9 - object size restriction in GCC: https://gcc.gnu.org/legacy-ml/gcc/2011-08/msg00221.html - glibc malloc restricts object size to <=PTRDIFF_MAX in checked_request2size() --- I'm not sure if we can reasonably do anything about this in the kernel, given that the kernel does not really have any idea of what userspace object sizes look like, or whether userspace even wants C semantics. But we can at least document it... @man-pages maintainer: Please wait a few days before applying this; I imagine there might be some discussion about this. man/man2/mmap.2 | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) base-commit: 4c4d9f0f5148caf1271394018d0f7381c1b8b400 diff --git a/man/man2/mmap.2 b/man/man2/mmap.2 index caf822103..9cb7dacf3 100644 --- a/man/man2/mmap.2 +++ b/man/man2/mmap.2 @@ -785,6 +785,23 @@ correspond to added or removed regions of the file is unspecified. An application can determine which pages of a mapping are currently resident in the buffer/page cache using .BR mincore (2). +.P +Unlike typical +.BR malloc (3) +implementations, +.BR mmap () +does not prevent creating objects larger than +.B PTRDIFF_MAX. +Objects that are larger than +.B PTRDIFF_MAX +only work in limited ways in standard C (in particular, pointer subtraction +results in undefined behavior if the result would be bigger than +.B PTRDIFF_MAX). +On top of that, GCC also assumes that no object is bigger than +.B PTRDIFF_MAX. +.B PTRDIFF_MAX +is usually half of the address space size; so for 32-bit processes, it is +usually 0x7fffffff (almost 2 GiB). .\" .SS Using MAP_FIXED safely The only safe use for