From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 744F63858D3C for ; Wed, 4 Oct 2023 17:36:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 744F63858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696440978; h=from:from: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; bh=C6UtYYg2l/WK5/7DQm68ul4ZJ60evOEK6N7YEdL9iPk=; b=Ij3l+SnC5gQ04G4dj6nG2m5Q+PtR5j4CkSMmAhsUeO3xmtCZjd7ovUtKgBPayyXU3utnkt UT7WZxWEgAeZJJ1XrTQia0xA1XWBx7imDoxeND79+SaT0CcM2TPfHLsGnntEROW1jHlIZu ex3m8JgWTYSNT8cX7LxW9hnp7zINxhY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-365-V8qJv3oZMHuggk8KrtXv5g-1; Wed, 04 Oct 2023 13:36:06 -0400 X-MC-Unique: V8qJv3oZMHuggk8KrtXv5g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 67A9318172D8; Wed, 4 Oct 2023 17:36:06 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C9CDF47AD4A; Wed, 4 Oct 2023 17:36:05 +0000 (UTC) From: Florian Weimer To: Volker =?utf-8?Q?Wei=C3=9Fmann?= Cc: libc-alpha@sourceware.org, Siddhesh Poyarekar Subject: Re: [PATCH v3] Fix FORTIFY_SOURCE false positive References: <20231003171844.9586-1-volker.weissmann@gmx.de> Date: Wed, 04 Oct 2023 19:36:04 +0200 In-Reply-To: <20231003171844.9586-1-volker.weissmann@gmx.de> ("Volker =?utf-8?Q?Wei=C3=9Fmann=22's?= message of "Tue, 3 Oct 2023 19:18:44 +0200") Message-ID: <87bkdeb88r.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Volker Wei=C3=9Fmann: > When -D_FORTIFY_SOURCE=3D2 was given during compilation, > sprintf and similar functions will check if their > first argument is in read-only memory and exit with > *** %n in writable segment detected *** > otherwise. To check if the memory is read-only, glibc > reads frpm the file "/proc/self/maps". If opening this > file fails due to too many open files (EMFILE), glibc > will now ignore this error. > > Fixes [BZ #30932] > > Signed-off-by: Volker Wei=C3=9Fmann > --- > sysdeps/unix/sysv/linux/readonly-area.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/sysdeps/unix/sysv/linux/readonly-area.c b/sysdeps/unix/sysv/= linux/readonly-area.c > index edc68873f6..ba32372ebb 100644 > --- a/sysdeps/unix/sysv/linux/readonly-area.c > +++ b/sysdeps/unix/sysv/linux/readonly-area.c > @@ -42,7 +42,9 @@ __readonly_area (const char *ptr, size_t size) > =09 to the /proc filesystem if it is set[ug]id. There has > =09 been no willingness to change this in the kernel so > =09 far. */ > -=09 || errno =3D=3D EACCES) > +=09 || errno =3D=3D EACCES > +=09 /* Process has reached the maximum number of open files. */ > +=09 || errno =3D=3D EMFILE) > =09return 1; > return -1; > } This whole thing is rather questionable. First of all, the compiler should detect the fact that a format argument to printf is a string literal and record that in the flags argument (which already exists for __printf_chk). Then we wouldn't have to do any %n security checks for most uses of %n. (The flags argument cannot be spoofed just by altering the string.) Siddhesh, is that something you could be working on? Even without that, if we are willing to trust the ld.so data structures, we can do the permission check in userspace for strings that come from .rodata. We an find the ELF object that contains them and check if the loadable segment has the right permissions (or we are in the RELRO area). After these changes, I think we can fail hard on /proc-related errors because they are very unlikely to happen. Thanks, Florian