From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 9F9E81F4B4 for ; Fri, 23 Oct 2020 08:34:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S375948AbgJWIe0 (ORCPT ); Fri, 23 Oct 2020 04:34:26 -0400 Received: from cloud.peff.net ([104.130.231.41]:40282 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S375765AbgJWIe0 (ORCPT ); Fri, 23 Oct 2020 04:34:26 -0400 Received: (qmail 27455 invoked by uid 109); 23 Oct 2020 08:34:25 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 23 Oct 2020 08:34:25 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 18078 invoked by uid 111); 23 Oct 2020 08:34:25 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Fri, 23 Oct 2020 04:34:25 -0400 Authentication-Results: peff.net; auth=none Date: Fri, 23 Oct 2020 04:34:24 -0400 From: Jeff King To: Johannes Schindelin via GitGitGadget Cc: git@vger.kernel.org, Jonathan Tan , Johannes Schindelin Subject: Re: [PATCH v2 3/3] sideband: add defense against packets missing a band designator Message-ID: <20201023083424.GD4012156@coredump.intra.peff.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Oct 19, 2020 at 07:35:42PM +0000, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > While there is currently no instance of code producing this type of > packet, if the `demultiplex_sideband()` would receive a packet whose > payload is not only empty but even misses the band designator, it would > mistake it for a flush packet. > > Let's defend against such a bug in the future. That seems reasonable, but I'm not sure if these ought to be BUG()s. Isn't it an indication that the other side sent us bogus input? That likely is a bug on the other end, but I think it should be a die(), just as we would produce for any other malformed protocol input. -Peff