From owner-freebsd-current@freebsd.org Thu Aug 20 06:49:19 2020 Return-Path: Delivered-To: freebsd-current@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 8D9413B34A6 for ; Thu, 20 Aug 2020 06:49:19 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 4BXFcZ5qJHz3yhf for ; Thu, 20 Aug 2020 06:49:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id r4so930097wrx.9 for ; Wed, 19 Aug 2020 23:49:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=I5GVI0p5TSj60QpfAwPqZBPI5sfLPNx0O4oxVSIBNgk=; b=deJqhIRQvYEuNXy+E4yYlp3EvHCXmQdU95lgaSCPPQAaIxKSZ9rtTlzIfflpoumX3N +K+vwBvYjVNZ/+YbzwoPnRqqqt1ftEdAQzW8zn7SuqX2l5Yk8DEKlX+hNCfnhmFN7tu3 8nN7ii4Sy2MKHfyqwgWF++BWDQcEH6HV2rUFBOSsxxzMDXTypOWwsG2Q/IWik8EW1aOJ qbboQIOalwbwftX/WOvPvC2gJfuuHiKCepn+ss7K9+3kFov6HBo8kDLAZHop9QN0AlL1 DtgZbzOuk3CMp9F6SeBYhuaVwCT5fFWbrrbBRYqwPvitaBnsdrNh3Eu+9js2GNX3Fi1Z ltfA== X-Gm-Message-State: AOAM530Sqi4cDJ4jMMQ7VCqXrmUZFd2zmVEGrv3x7zNv7xL199f2/aOx YMWfiRpnZcoVHv0JK6bZQflWpaUUfhM= X-Google-Smtp-Source: ABdhPJw/QdQiCagQAZno9iTjbKRXZbuYAs1gHZMnxi4tXSr/DPsihcXr7g3aYjQZCw5nDpnyWLFI0Q== X-Received: by 2002:a5d:5048:: with SMTP id h8mr1573317wrt.424.1597906156862; Wed, 19 Aug 2020 23:49:16 -0700 (PDT) Received: from ernst.home (pd9e23482.dip0.t-ipconnect.de. [217.226.52.130]) by smtp.gmail.com with ESMTPSA id i4sm2286111wrw.26.2020.08.19.23.49.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 23:49:16 -0700 (PDT) Date: Thu, 20 Aug 2020 08:49:15 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: PRINTF_BUFR_SIZE dangerous? Message-ID: <20200820084915.4967e80b@ernst.home> In-Reply-To: <20200820083332.59d7fbbb@ernst.home> References: <20200820083332.59d7fbbb@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXFcZ5qJHz3yhf X-Spamd-Bar: / X-Spamd-Result: default: False [-0.32 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.368]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[217.226.52.130:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.05)[0.048]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 06:49:19 -0000 On Thu, 20 Aug 2020 08:33:32 +0200 Gary Jennejohn wrote: > It seems like PRINTF_BUFR_SIZE is a kernel fault waiting to happen. > > Only /usr/src/sys/cam/cam_xpt.c asserts that it's <= a maximum value of > 512 bytes. > > /usr/src/sys/kern/tty.c uses it to malloc space without checking its size. > > /usr/src/sys/dev/xen/console/xen_console.c and /usr/src/sys/kern/subr_prf.c > blindly use it to allocate a buffer on the kernel stack. > > /usr/src/sys/geom/geom_subr.c and /usr/src/sys/geom/geom_io.c check whether > it's defined and set it to 64 if it isn't. Otherwise it's simply used to > allocate a buffer on the kernel stack. > > A user who doesn't really understand the purpose of PRINTF_BUFR_SIZE might > think "the bigger the better" and set it to be multi-megabytes in size. > > I may be paranoid, but it seems like PRINTF_BUFR_SIZE should be checked > everywhere the way that cam_xpt.c does it. > OK, I decided to try setting PRINTF_BUFR_SIZE to (1024*1024) and the static assert in /usr/src/sys/cam/cam_xpt.c saved the day. Still, if a user isn't using scbus the problem would still exist. -- Gary Jennejohn