From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com>, Arnd Bergmann <arnd@arndb.de>, mst@redhat.com, Amit Shah <amit@kernel.org>, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, elena.reshetova@intel.com, kirill.shutemov@linux.intel.com Subject: Re: [PATCH v1 1/6] virtio console: Harden multiport against invalid host input Date: Thu, 19 Jan 2023 20:18:12 +0100 [thread overview] Message-ID: <Y8mXdFms3CzPnW+6@kroah.com> (raw) In-Reply-To: <87fsc6qrvx.fsf@ubik.fi.intel.com> 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 _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: mst@redhat.com, jasowang@redhat.com, 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>, Amit Shah <amit@kernel.org>, Arnd Bergmann <arnd@arndb.de> Subject: Re: [PATCH v1 1/6] virtio console: Harden multiport against invalid host input Date: Thu, 19 Jan 2023 20:18:12 +0100 [thread overview] Message-ID: <Y8mXdFms3CzPnW+6@kroah.com> (raw) In-Reply-To: <87fsc6qrvx.fsf@ubik.fi.intel.com> 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
next prev parent reply other threads:[~2023-01-19 19:18 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-19 13:57 [PATCH v1 0/6] Harden a few virtio bits Alexander Shishkin 2023-01-19 13:57 ` [PATCH v1 1/6] virtio console: Harden multiport against invalid host input Alexander Shishkin 2023-01-19 15:17 ` Greg Kroah-Hartman 2023-01-19 15:17 ` Greg Kroah-Hartman 2023-01-19 18:52 ` Alexander Shishkin 2023-01-19 19:18 ` Greg Kroah-Hartman [this message] 2023-01-19 19:18 ` Greg Kroah-Hartman 2023-01-19 19:34 ` Alexander Shishkin 2023-01-20 13:01 ` Michael S. Tsirkin 2023-01-20 13:01 ` Michael S. Tsirkin 2023-01-20 15:51 ` Alexander Shishkin 2023-01-19 13:57 ` [PATCH v1 2/6] virtio console: Harden port adding Alexander Shishkin 2023-01-19 15:20 ` Greg Kroah-Hartman 2023-01-19 15:20 ` Greg Kroah-Hartman 2023-01-19 17:48 ` Alexander Shishkin 2023-01-19 18:57 ` Greg Kroah-Hartman 2023-01-19 18:57 ` Greg Kroah-Hartman 2023-01-19 20:13 ` Alexander Shishkin 2023-01-20 7:15 ` Greg Kroah-Hartman 2023-01-20 7:15 ` Greg Kroah-Hartman 2023-01-27 11:02 ` Michael S. Tsirkin 2023-01-27 11:02 ` Michael S. Tsirkin 2023-01-27 11:55 ` Alexander Shishkin 2023-01-27 12:12 ` Michael S. Tsirkin 2023-01-27 12:12 ` Michael S. Tsirkin 2023-01-27 12:47 ` Alexander Shishkin 2023-01-27 13:31 ` Greg Kroah-Hartman 2023-01-27 13:31 ` Greg Kroah-Hartman 2023-01-27 14:17 ` Alexander Shishkin 2023-01-27 14:37 ` Greg Kroah-Hartman 2023-01-27 14:37 ` Greg Kroah-Hartman 2023-01-27 14:46 ` Michael S. Tsirkin 2023-01-27 14:46 ` Michael S. Tsirkin 2023-02-02 12:02 ` Reshetova, Elena 2023-01-27 13:52 ` Michael S. Tsirkin 2023-01-27 13:52 ` Michael S. Tsirkin 2023-01-20 12:59 ` Michael S. Tsirkin 2023-01-20 12:59 ` Michael S. Tsirkin 2023-01-19 13:57 ` [PATCH v1 3/6] virtio 9p: Fix an overflow Alexander Shishkin 2023-01-20 12:54 ` Michael S. Tsirkin 2023-01-20 12:54 ` Michael S. Tsirkin 2023-01-20 16:29 ` Alexander Shishkin 2023-01-19 13:57 ` [PATCH v1 4/6] virtio console: Harden control message handling Alexander Shishkin 2023-01-19 15:22 ` Greg Kroah-Hartman 2023-01-19 15:22 ` Greg Kroah-Hartman 2023-01-20 12:45 ` Michael S. Tsirkin 2023-01-20 12:45 ` Michael S. Tsirkin 2023-01-20 16:41 ` Alexander Shishkin 2023-01-27 10:58 ` Michael S. Tsirkin 2023-01-27 10:58 ` Michael S. Tsirkin 2023-01-27 12:04 ` Alexander Shishkin 2023-01-19 13:57 ` [PATCH v1 5/6] virtio_net: Guard against buffer length overflow in xdp_linearize_page() Alexander Shishkin 2023-01-20 13:09 ` Michael S. Tsirkin 2023-01-20 13:09 ` Michael S. Tsirkin 2023-01-19 13:57 ` [PATCH v1 6/6] virtio_ring: Prevent bounds check bypass on descriptor index Alexander Shishkin 2023-01-20 12:56 ` Michael S. Tsirkin 2023-01-20 12:56 ` Michael S. Tsirkin 2023-01-20 11:55 ` [PATCH v1 0/6] Harden a few virtio bits Michael S. Tsirkin 2023-01-20 11:55 ` Michael S. Tsirkin 2023-01-20 12:32 ` Alexander Shishkin 2023-01-20 12:40 ` Michael S. Tsirkin 2023-01-20 12:40 ` Michael S. Tsirkin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y8mXdFms3CzPnW+6@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=ak@linux.intel.com \ --cc=alexander.shishkin@linux.intel.com \ --cc=amit@kernel.org \ --cc=arnd@arndb.de \ --cc=elena.reshetova@intel.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.