Message ID | 20230119135721.83345-2-alexander.shishkin@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp9237wrn; Thu, 19 Jan 2023 20:37:08 -0800 (PST) X-Google-Smtp-Source: AMrXdXt54PTzTYUurLadhXiGSqtF/5gzzsV5vUbuX1ZuZ7MyooOuBMUBDTq1crnsLlHwrkiV4rg+ X-Received: by 2002:a17:90b:392:b0:223:f4e9:b22b with SMTP id ga18-20020a17090b039200b00223f4e9b22bmr14044726pjb.41.1674189427903; Thu, 19 Jan 2023 20:37:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674189427; cv=none; d=google.com; s=arc-20160816; b=GTA07D/2aOQjBrp1wSyuBuIH4d6NNicVHX214oS5WnBG6qaOxqz5EwaN9HIU/EAqhy vIEBsTG30a6MnaAXaxSQmtlDzsS15jMjwaSFfv7yGPZYGcmfEmLdkzFJEoSX3DATe2GA As78/yWBdqcAcfgyAs1F/ApvBMj98zzi8+RBrr3r+KnlPr59AfEHlV6DV+SOEE42uVjP cNVFrtkj6yvLEMwAHOM7agtXTQYgDHN1njDPWDW/Xavbmr7E2cXeAsB/RwIGfS038b9a XDo3+hm57xAoKjf/SGOFmwsi+VZ6Sxys1SD/LjKTMsYEJm0ufqlPiHnJwYpQ1pSXpGh0 56Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=lVSU+pfVmuoZ5d/i+9Rn95vuMKS1U8q2mILsQXdSSbQ=; b=EfrKq/wkQp+96hJY4mwMcxroSz0J2wl4eDVKdS8ZPaj+opTIum+M4AOdkUcS0wV37+ u4R0i8qZORzwCUC30XhJcgcgqvAndCf+MctvDEvmsFRoAlDETmcFgw1yEldszCPFfrjN bUC5iF8/i/OFjKNYNqZX3EonsaT/U2NuJuvat+TbYsciSTXU0023OmSCHKH30qV7rj2N DQgnlNVnmkk/MT1PNFF7MhzWy+JxwN4e4vQiOpg4xmG67TVchYTiIXUEXYElypX3hMqi lA+ccDUhOrf9v3Vc4k+kDPD4WaTNDoe7NBI/n//G6b6M7goaK70RT/JTrOxPsukMA5Zz cVnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ak1dukcs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f36-20020a17090a702700b00219044e1bbdsi1271860pjk.25.2023.01.19.20.36.56; Thu, 19 Jan 2023 20:37:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ak1dukcs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230209AbjATEgc (ORCPT <rfc822;xxoosimple@gmail.com> + 99 others); Thu, 19 Jan 2023 23:36:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229982AbjATEgC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 19 Jan 2023 23:36:02 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52DD9BC8B2 for <linux-kernel@vger.kernel.org>; Thu, 19 Jan 2023 20:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674189238; x=1705725238; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=rYq6vhVbEN0C0wtg/aG1JBfgnzFIZAFF2Xt8UqDJh9o=; b=ak1dukcsXVxzzzj/T9FTs9vDePHlwIZ8xVA+GpPqUekQLimUrP/qinSM GUvPmSkIUHZ5TuYenTVb5Z8P9Qvm7FSjKm/o9nLfY7DqVFKlaZ0RZxJLs w6vs0SiMcFeynBT7xOOB/XjzFsrfIkyH8BYCszk/+q9YXu6HtBWy2+UV6 XWqDUZU8EYabuHuWF4pYHmAMo79ZwhnnQ4A1WM34/2TINkapXJp9JE/Kf kF3uaY4ksEA/kntzUMoklgR6HmshZTAqusoidW8haNQWaN/hh8kdAezmx SKuTZc4VILdmaa6GrXw7vf0ZFYwUcYaBESQRZs1rGUG0eoOhlLpLSYLya w==; X-IronPort-AV: E=McAfee;i="6500,9779,10594"; a="411526091" X-IronPort-AV: E=Sophos;i="5.97,229,1669104000"; d="scan'208";a="411526091" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2023 05:57:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10594"; a="988993908" X-IronPort-AV: E=Sophos;i="5.97,229,1669104000"; d="scan'208";a="988993908" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by fmsmga005.fm.intel.com with ESMTP; 19 Jan 2023 05:57:03 -0800 From: Alexander Shishkin <alexander.shishkin@linux.intel.com> To: mst@redhat.com, jasowang@redhat.com Cc: virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, elena.reshetova@intel.com, kirill.shutemov@linux.intel.com, Andi Kleen <ak@linux.intel.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Amit Shah <amit@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: [PATCH v1 1/6] virtio console: Harden multiport against invalid host input Date: Thu, 19 Jan 2023 15:57:16 +0200 Message-Id: <20230119135721.83345-2-alexander.shishkin@linux.intel.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230119135721.83345-1-alexander.shishkin@linux.intel.com> References: <20230119135721.83345-1-alexander.shishkin@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755464708001202374?= X-GMAIL-MSGID: =?utf-8?q?1755514853449626561?= |
Series |
Harden a few virtio bits
|
|
Commit Message
Alexander Shishkin
Jan. 19, 2023, 1:57 p.m. UTC
From: Andi Kleen <ak@linux.intel.com> It's possible for the host to set the multiport flag, but pass in 0 multiports, which results in: BUG: KASAN: slab-out-of-bounds in init_vqs+0x244/0x6c0 drivers/char/virtio_console.c:1878 Write of size 8 at addr ffff888001cc24a0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0-rc1-140273-gaab0bb9fbaa1-dirty #588 Call Trace: init_vqs+0x244/0x6c0 drivers/char/virtio_console.c:1878 virtcons_probe+0x1a3/0x5b0 drivers/char/virtio_console.c:2042 virtio_dev_probe+0x2b9/0x500 drivers/virtio/virtio.c:263 call_driver_probe drivers/base/dd.c:515 really_probe+0x1c9/0x5b0 drivers/base/dd.c:601 really_probe_debug drivers/base/dd.c:694 __driver_probe_device+0x10d/0x1f0 drivers/base/dd.c:754 driver_probe_device+0x68/0x150 drivers/base/dd.c:786 __driver_attach+0xca/0x200 drivers/base/dd.c:1145 bus_for_each_dev+0x108/0x190 drivers/base/bus.c:301 driver_attach+0x30/0x40 drivers/base/dd.c:1162 bus_add_driver+0x325/0x3c0 drivers/base/bus.c:618 driver_register+0xf3/0x1d0 drivers/base/driver.c:171 ... Add a suitable sanity check. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Amit Shah <amit@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- drivers/char/virtio_console.c | 3 +++ 1 file changed, 3 insertions(+)
Comments
On Thu, Jan 19, 2023 at 08:52:02PM +0200, Alexander Shishkin wrote: > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes: > > > On Thu, Jan 19, 2023 at 03:57:16PM +0200, Alexander Shishkin wrote: > >> From: Andi Kleen <ak@linux.intel.com> > >> > >> --- a/drivers/char/virtio_console.c > >> +++ b/drivers/char/virtio_console.c > >> @@ -1843,6 +1843,9 @@ static int init_vqs(struct ports_device *portdev) > >> int err; > >> > >> nr_ports = portdev->max_nr_ports; > >> + if (use_multiport(portdev) && nr_ports < 1) > >> + return -EINVAL; > >> + > >> nr_queues = use_multiport(portdev) ? (nr_ports + 1) * 2 : 2; > >> > >> vqs = kmalloc_array(nr_queues, sizeof(struct virtqueue *), GFP_KERNEL); > >> -- > >> 2.39.0 > >> > > > > Why did I only get a small subset of these patches? > > I did what get_maintainer told me. Would you like to be CC'd on the > whole thing? If you only cc: me on a portion of the series, I guess you only want me to apply a portion of it? if so, why is it a longer series? > > And why is the whole thread not on lore.kernel.org? > > That is a mystery, some wires got crossed between my smtp and vger. I > bounced the series to lkml just now and at least some of it seems to > have landed on lore. > > > And the term "hardening" is marketing fluff. Just say, "properly parse > > input" or something like that, as what you are doing is fixing > > assumptions about the data here, not causing anything to be more (or > > less) secure. > > > > But, this still feels wrong. Why is this happening here, in init_vqs() > > and not in the calling function that already did a bunch of validation > > of the ports and the like? Are those checks not enough? if not, fix it > > there, don't spread it out all over the place... > > Good point! And there happens to already be 28962ec595d70 that takes > care of exactly this case. I totally missed it. So this series is not needed? Or just this one? greg k-h
On Thu, Jan 19, 2023 at 03:57:16PM +0200, Alexander Shishkin wrote: > From: Andi Kleen <ak@linux.intel.com> > > It's possible for the host to set the multiport flag, but pass in > 0 multiports, which results in: > > BUG: KASAN: slab-out-of-bounds in init_vqs+0x244/0x6c0 drivers/char/virtio_console.c:1878 > Write of size 8 at addr ffff888001cc24a0 by task swapper/1 > > CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0-rc1-140273-gaab0bb9fbaa1-dirty #588 > Call Trace: > init_vqs+0x244/0x6c0 drivers/char/virtio_console.c:1878 > virtcons_probe+0x1a3/0x5b0 drivers/char/virtio_console.c:2042 > virtio_dev_probe+0x2b9/0x500 drivers/virtio/virtio.c:263 > call_driver_probe drivers/base/dd.c:515 > really_probe+0x1c9/0x5b0 drivers/base/dd.c:601 > really_probe_debug drivers/base/dd.c:694 > __driver_probe_device+0x10d/0x1f0 drivers/base/dd.c:754 > driver_probe_device+0x68/0x150 drivers/base/dd.c:786 > __driver_attach+0xca/0x200 drivers/base/dd.c:1145 > bus_for_each_dev+0x108/0x190 drivers/base/bus.c:301 > driver_attach+0x30/0x40 drivers/base/dd.c:1162 > bus_add_driver+0x325/0x3c0 drivers/base/bus.c:618 > driver_register+0xf3/0x1d0 drivers/base/driver.c:171 > ... > > Add a suitable sanity check. > > Signed-off-by: Andi Kleen <ak@linux.intel.com> > Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> > Cc: Amit Shah <amit@kernel.org> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > --- > drivers/char/virtio_console.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index 6a821118d553..f4fd5fe7cd3a 100644 > --- a/drivers/char/virtio_console.c > +++ b/drivers/char/virtio_console.c > @@ -1843,6 +1843,9 @@ static int init_vqs(struct ports_device *portdev) > int err; > > nr_ports = portdev->max_nr_ports; > + if (use_multiport(portdev) && nr_ports < 1) > + return -EINVAL; > + > nr_queues = use_multiport(portdev) ? (nr_ports + 1) * 2 : 2; > > vqs = kmalloc_array(nr_queues, sizeof(struct virtqueue *), GFP_KERNEL); Weird. Don't we already check for that? /* Don't test MULTIPORT at all if we're rproc: not a valid feature! */ if (!is_rproc_serial(vdev) && virtio_cread_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT, struct virtio_console_config, max_nr_ports, &portdev->max_nr_ports) == 0) { if (portdev->max_nr_ports == 0 || portdev->max_nr_ports > VIRTCONS_MAX_PORTS) { dev_err(&vdev->dev, "Invalidate max_nr_ports %d", portdev->max_nr_ports); err = -EINVAL; goto free; } multiport = true; } > -- > 2.39.0
"Michael S. Tsirkin" <mst@redhat.com> writes: > Weird. Don't we already check for that? > > /* Don't test MULTIPORT at all if we're rproc: not a valid feature! */ > if (!is_rproc_serial(vdev) && > virtio_cread_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT, > struct virtio_console_config, max_nr_ports, > &portdev->max_nr_ports) == 0) { > if (portdev->max_nr_ports == 0 || > portdev->max_nr_ports > VIRTCONS_MAX_PORTS) { > dev_err(&vdev->dev, > "Invalidate max_nr_ports %d", > portdev->max_nr_ports); > err = -EINVAL; > goto free; > } > multiport = true; > } Yes, I missed this earlier. I'll drop this patch. Thanks, -- Alex
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 6a821118d553..f4fd5fe7cd3a 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1843,6 +1843,9 @@ static int init_vqs(struct ports_device *portdev) int err; nr_ports = portdev->max_nr_ports; + if (use_multiport(portdev) && nr_ports < 1) + return -EINVAL; + nr_queues = use_multiport(portdev) ? (nr_ports + 1) * 2 : 2; vqs = kmalloc_array(nr_queues, sizeof(struct virtqueue *), GFP_KERNEL);