From mboxrd@z Thu Jan 1 00:00:00 1970 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 802CCC3ABA3 for ; Fri, 2 May 2025 12:27:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E972B6B0088; Fri, 2 May 2025 08:27:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1D506B0089; Fri, 2 May 2025 08:27:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBEB66B008A; Fri, 2 May 2025 08:27:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AA3B16B0088 for ; Fri, 2 May 2025 08:27:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 475761A1822 for ; Fri, 2 May 2025 12:27:58 +0000 (UTC) X-FDA: 83397894636.16.A8BE82B Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf19.hostedemail.com (Postfix) with ESMTP id 586161A0004 for ; Fri, 2 May 2025 12:27:56 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Fs5op930; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746188876; a=rsa-sha256; cv=none; b=M2afRkrOqI1m+SQg8UfGibRJHdEVYmembIvqcfdL2Ph8YDBFqxyzCL4Jb9TLBH1UH2Lxb4 SwBPWdRw50zQtFS3Zk8+KK50bwRG6pgoFF9XWa+vQrueLZV4zux4LhsFrl6kApdz7la/O6 Fpip02MAqgIo1u58lS5X+murtzae8Ik= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746188876; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KED6TVM6KhxnWvS+bAlYXam1Na+H4EKzj+x4CN+guAE=; b=BmnRT2ZADxEGPIJgsgq28Qerw+o8jASVDFF1fhh/niisFPphFv378uwRboEyFBV1KR/n7O IfeTjxBhE2Zfop+n/30h/mMCGzjd6MaC2Ew9EQAxa0r7aYi01XdGcZ2YVkuWZhwOJLmsxj eoAXBg1tkJ5M5P46k409bS6J4OqZwfg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Fs5op930; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@google.com Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5f88f236167so9132a12.0 for ; Fri, 02 May 2025 05:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746188875; x=1746793675; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KED6TVM6KhxnWvS+bAlYXam1Na+H4EKzj+x4CN+guAE=; b=Fs5op930J07dw1r/T2+wtGjXUiMYoMn6E7eGPQaz6N4dAz1iJ0Z6Ui5e1WqA8ByHqP +Y9YzrfHU2xGohdTl77+OmtkcI7yEKosI9dEww9Al7oZ7+kY2ymSbltyC6a7JeSg7wlH 6cYpYn/jiIelDLwTYBHiql9r6XDeoxGFaWa9B/s7cDQENb3S6kEFnq285FAOS/RFsZYL Ublx9AjaGrEaa5T279t/PNLRjfoSMCBaySZqaMTrit8BLomywI840YbegSJgO7Z2L+sa p8De/db0mPRhX3n30jUpRZGznZHlKNcygVYyVzGozi64Tg/Xd374Q69S2RVyFrRSq7/w wzkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746188875; x=1746793675; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KED6TVM6KhxnWvS+bAlYXam1Na+H4EKzj+x4CN+guAE=; b=Bi2kUwfxat8pRbSpiTeDe+xIzKOF2Qu+ujwyt09MH7EE4Y0B3pZVhd+wfDEotlHQ6y 1O68jrGESGm1NDDOMthlJkC5azY+VhCuAhbJS3x5paP7N7FvNXA3c9HnVlXa7GKk/Ndg El8xtC7fmckI457YkBtAeYMzRzuo5tQNzj77KurIu5SHEAUySuvwMckIn3+fNAvGdTvO 5LNc6yWyTTTyf4wyn0HDjT89yLsWomGL9IQV8ESZN0veOjDtkc3xj+iP7661DVfwPcWG cZzvwl0N7TmZQz6VEmKzXm9LmO3fkF6WrrpZ5p+275+MDJ3Nnm+Wjv4h/rFSB782NLFc 12Qw== X-Forwarded-Encrypted: i=1; AJvYcCVCFzZElBqDUFVHoUxnioZ8VtgYAlmVy5s73h+eZBrUDZV5/4v0TUYe+Bkcb/WcRfIuKqd+V3JI2g==@kvack.org X-Gm-Message-State: AOJu0YwPVj9dDcW+Cg4GDx6hquXxxkeiYX6Z7VwZB7p8PM8JByguebk+ UFv13dSXfKYsegthJcEIUuAe7TsovU29cSAN6Gpcgq4EacqYSc8xQ08Zs1O30tc4/j4m9nG4+5I xyEBUSsnmS+FShsgR3pJiMXJCOS29FB0CR6XW X-Gm-Gg: ASbGncvQ8ra4ZWX57PtXl3KNcTUf2vk//lL8TyWOJqA6rvjv5jlk5TZ0o5aiz4Eb1PG QBP8iX4IjgJFcgRwEkHYMS5PKOz8F9biUnqKhKZxYPppn9ckSRD2914lF4dBgqNUuZb+W8tE4SR 6EFSz/Rx9SJ6syQWWAUuSVcZyDPxcV0ARD0iy6Z7CDqm61is8PhDcFHN2x2NTJ X-Google-Smtp-Source: AGHT+IGTVutwBhlkfvR47Zkz95WH0RV6UGYqpx4CFTVUk1SwzLQJ0cbpfA57taFIdoXJzu1hG7pleUmKhHCkrUCRMRA= X-Received: by 2002:a50:d556:0:b0:5e6:15d3:ffe7 with SMTP id 4fb4d7f45d1cf-5f918c2a177mr168900a12.7.1746188874342; Fri, 02 May 2025 05:27:54 -0700 (PDT) MIME-Version: 1.0 References: <20250429164359.2699330-1-jannh@google.com> In-Reply-To: From: Jann Horn Date: Fri, 2 May 2025 14:27:18 +0200 X-Gm-Features: ATxdqUEcXm4IiDr4XYWSdbbI_BiNAizfd7NzC2o3ztpx8sL9j64phvDx-UHiZSw Message-ID: Subject: Re: [PATCH man v2] mmap.2: Document danger of mappings larger than PTRDIFF_MAX To: Alejandro Colomar Cc: linux-man@vger.kernel.org, Andrew Morton , "Liam R . Howlett" , Lorenzo Stoakes , Vlastimil Babka , linux-mm@kvack.org, Jakub Wilk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 586161A0004 X-Stat-Signature: hmwu4hwf7cn5pey4kpzn17oyfuu4kb86 X-Rspam-User: X-HE-Tag: 1746188876-167410 X-HE-Meta: U2FsdGVkX18XdQdEdGQ8FeCHkk3yI5DjBqCEGB9zSp9MZB21m1e9L+lCrnamvUqy1cokdw/rRjkmHqwvS7OliwCX2oEVyw18Cjlk4UTwdcQuAyPcoIk62qqjBhnQ+XbqXURIBKX6qNT+syKBjTA8LO3c8imveo1sPv2jEB1Qg+6IN8aDizcLAjCc5iCvX1EWbuHWt2HjZepybdN+gAfLULKa6aefZaA60330QzKjg9B3hpwG0ZVltjIYTBhC1JLP6V56GR9uTRRXg1iCIKkvfbwU9YoNdi1sunyv8+r59kIUPIWolBFBu/YQxt2lXanOkIgJK95iKN/ZEHo52FnqVzthkDd/ihTwlLmj0rys8ljWrQ2rEx6rWobXlSvX7C/KpT36jNyAATA2tf+ppFFup/novK1BnDHh6qsxHx47B5ww8wvm9Spt8gA0dFnrfZhEMQAczthXmKtOnyP7fOc5OpG7IycBSFhoV6Sv4cV3Kmb1YlM4Cx7sVYYO/MPFf0mLxyQU3YtGITutWyfXEA8rf9MTQ4BWEi/GYGjZqCub0Tz9GNqMVecQHyhPr9TRcYDropU46vdaQRVWJgAvY4zdWQ1tCsHeCniLri/UwRDy0augUKuv1YzhoedS4IaRRZMlVKM3KuHOAOB4SPtQRvgfhRK6MH9JyfaZJVUj+MbR0ppo1Q9XgKMTVlBL6lmsGiy5FChXehGMB+i3QYpwjnioz0mlW8j8OHCJctqeM1R78FW9+zaokCso9ilpxiFdU/gLoSULX3RT3zanAwy44O9Bl2RF9+QXO2LfWobqms9VmeDkH9uxiBILNgXwBASRo3v4qz9hFgPVSIrERzkceNppMHdhaD+2cavi9CCzFDwfy7d42Csv7suW5N+F1qaimAWwJJGC93pXWmuSourTc+Y8yfXPF3phKcu/Nl5JqlGpLD8aawBgppJNj/ch8RZLNBsZkeF3E2i8StStvJI4EGU L1XXZVKd qQEdTSsbL9h77WjKzZLg+0ukC7+Em0qRPO95zhZF4chXYbG5IdYPxeMfvvAe3VxcRSU86pGsgsbjYGnImCzPZPeVvJGq34DTEDPJIAmpD3M94LQPDSAObcu7z3qywsjZ7Dw4WAPVPdHL9K4+XNZTfwAAqhRDCkyYgAbkW+1QuvrhybHSzaNaueOo5pgZOOkUs9E6NiCCQBugXaiwdEFYb/ts+Bm5s6e+RnaKOAQ/HbzqwhtqhCoIeaqn69OkkE8eHAzMZKlB0YfMGRZyRFuNV9XThCcJfcAu5a/nGB5rUkgE2mgZ5pUKpr8XCnvQdCH4OhT20wvAy1acWg2fW+hwkljDU4KiBzAM9ivD3PLFD0vY/ueK7I1f1JVScLqIquSlkRfKOTLi6kop3wwPLVFCl+zNlwnFlYy0rqSp+6KdWhXLTwxqfc8aHQR82b/D6oaH/BlbwH83cI+pNHScmtbyyaGZrqc6TpBSA2Y0qJhaaq40NX1Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, May 1, 2025 at 6:43=E2=80=AFPM Alejandro Colomar w= rote: > On Tue, Apr 29, 2025 at 06:43:59PM +0200, Jann Horn wrote: > > References: > > - C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pd= f > > 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 <=3DPTRDIFF_MAX in > > checked_request2size() since glibc v2.30 (released in 2019, as point= ed > > out by Jakub Wilk): > > https://sourceware.org/cgit/glibc/commit/?id=3D9bf8e29ca136094f > > Thanks! I've applied the patch. See some comments below. > Thanks! > > +Unlike typical > > +.BR malloc (3) > > +implementations, > > +.BR mmap () > > +does not prevent creating objects larger than > > +.BR PTRDIFF_MAX . > > +Objects that are larger than > > +.B PTRDIFF_MAX > > +only work in limited ways in standard C > > I've removed 'standard', since in any C it is problematic. > > Is it okay to you? (We're still in time to amend if you prefer > something else.) Sounds good to me.