From owner-svn-src-all@freebsd.org Mon May 18 20:17:44 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 834302DC27C; Mon, 18 May 2020 20:17:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Qr0m2sVfz4Hs8; Mon, 18 May 2020 20:17:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi1-f195.google.com with SMTP id y85so5436422oie.11; Mon, 18 May 2020 13:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Ms4jPGP6m/mR1GU56bT9w5r+eAlcTC552LBh1ggWsOk=; b=ig2/7FoeXSDCijkbHrOFLjmETDnTwM3K75BsZFRahAAOHdS+ZB4OOOdpvbZNz6XT+o BycTi8k6WLm6MWWJtG1VELZB88PxWFuOWZ0pxhKiqksgjAXW0wOxKdvCohDjd8bVCmxX SvFauCWSf4tybEfmjUy3PQSI1VCEtcoh08PbwbSIdehfAJgP6rE3i7bBVBrzr7IA2roi TfUen+CY/lleWzJCfBfDgN82QwZZLm5rLNDD4dcqrRAhnroxMA53oTAjzbpyPsqo7+M8 M1bQ6Pe3zRD72PYAjm2HPo3LGPFs/GieoQ0P8JZ50kmwPYfmMnJnn9QKxlWahANGcnCt uCjw== X-Gm-Message-State: AOAM531gWJYrBX6vgqn6r5KMgBFgOk2nyeHyIX14lxI12bEI80OS0QrB E66Vd1ktIbnt8SrDtri80KV40j97 X-Google-Smtp-Source: ABdhPJz0yE74wa0vS9ghTLPsnV//NkKZE8iOcsEU/cQmgtzw+sqmU0oQsoSa6A7ZbDqGcjJ+Sph1MA== X-Received: by 2002:a05:6808:282:: with SMTP id z2mr745841oic.101.1589833062983; Mon, 18 May 2020 13:17:42 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com. [209.85.210.45]) by smtp.gmail.com with ESMTPSA id l196sm3361018oih.25.2020.05.18.13.17.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 13:17:42 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id f18so5165457otq.11; Mon, 18 May 2020 13:17:42 -0700 (PDT) X-Received: by 2002:a9d:70ca:: with SMTP id w10mr4086878otj.216.1589833061839; Mon, 18 May 2020 13:17:41 -0700 (PDT) MIME-Version: 1.0 References: <202005181007.04IA713t089936@repo.freebsd.org> <064C2DCD-6279-4442-A900-0ECCD50CC4FA@freebsd.org> In-Reply-To: <064C2DCD-6279-4442-A900-0ECCD50CC4FA@freebsd.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 18 May 2020 13:17:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r361209 - head/sys/netinet To: Michael Tuexen Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49Qr0m2sVfz4Hs8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 20:17:44 -0000 Hi Michael, On Mon, May 18, 2020 at 12:05 PM Michael Tuexen wrote: > > > On 18. May 2020, at 20:23, Conrad Meyer wrote: > > > If truncation is intended, the GCC warning is spurious. Given how > > often snprintf is used in this way, I wonder if it would make sense to > > just disable it across the entire tree. Regardless, IMO it makes > > The issue wasn't reported against the kernel code, but running the code > in userland. I don't really control the flags people are using. Sure. You can certainly ignore user reports corresponding to bogus flags, though, and encourage use of various flags. > OK. I'll revert this change and replace it upstream by something like > > #if defined(__FreeBSD_) > snprintf(msg, sizeof(msg), "Never sent serial number %8.8x", seri= al_num) > #else > if (snprintf(msg, sizeof(msg), "Never sent serial number %8.8x", = serial_num) < 0) { > msg[0] =3D '\0'; > } > #endif This seems like a messy solution. I'd suggest either putting unconditional "msg[0] =3D '\0';" before snprintf() invocations, or defining an snprintf wrapper function for non-FreeBSD platforms and using it universally. > I don't know if other platforms guarantee that snprintf() can't fail. > If it fails, the stack would send out un-initialized stack memory on > the network. Sure, that's a good concern. That said, Glibc: https://github.com/bminor/glibc/blob/5f72f9800b250410cad3abfeeb09469= ef12b2438/libio/vsnprintf.c#L93-L114 (always nul terminates) MS: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/snprin= tf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=3Dvs-2019 ("The snprintf function always stores a terminating null character=E2=80=A6= ") OpenBSD: https://github.com/openbsd/src/blob/master/lib/libc/stdio/vsnprint= f.c#L60-L63 (always nul terminates) NetBSD: https://github.com/NetBSD/src/blob/trunk/lib/libc/stdio/vsnprintf.c= #L97-L101 (always nul terminates) Linux (kernel): https://elixir.bootlin.com/linux/latest/source/lib/vsprintf.c#L2645 (always nul terminates) None of these are conditional on error status. The only exception I found is musl libc, and in that it is a case you cannot encounter here (size > INT_MAX). Arguably this is a bug in musl libc. I did not dive deeper into musl and determine whether other errors were nul terminated or not. Conrad P.S., It seems dubious to be sending diagnostic formatted error messages out across the network.