From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7FA02C4332F for ; Mon, 6 Nov 2023 12:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=o7yRZgXuRXnQO0NoW2YdP6sTjrVyQiS2VRYs3lXow1I=; b=mzMmzP4ty4z2Qr JXLCwTk3RomVkXYOxHMthOS5sKrITgRDuyrxBbzIxUAKPVmSrQ/8HfBAWKjuR5FwWW/0xAeQuJscT xqxzNzv+zBxUmHxnvIgQU6RScNc/mTmHp2JVJaLbIYQtpURY6qXiPNkBwY8nfx2fF+7dgt9wi0qUD HwhaHnawUyg7SwmMpbSFUGcfcpBgC1+uocbgA28+7H9G2vnC7MGw7kYzsUqg/83QkqXzlnAlI7xUf p73HF9dnv/NJaEM9UsDfW+IPADAV5oLtd6HrDCMi9bTFOyvzLcfmelFTmw98248xj0WQB0IJUHYyJ H4ERzpsq8+f413jVBWnQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qzyu4-00GeZS-2p; Mon, 06 Nov 2023 12:40:28 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qzyu1-00GeYq-1X for linux-arm-kernel@lists.infradead.org; Mon, 06 Nov 2023 12:40:27 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-9db6cf8309cso626267166b.0 for ; Mon, 06 Nov 2023 04:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699274422; x=1699879222; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=q/j5ZdORQp2c8s4IMJhl7QIq4MbRa4fgg20gEx4WXX8=; b=bHFfJgTETbKlhOch9sfzkHt52DUzaZzdkrtFcEWyp6Nri39KjV6qbXx4P4deVOWRBk 9UJUhs9fCIUYoHsbHQ90OkcgX1Z1Sw7JX0qxTRktELu88VXuWkrnx6i3QLvG/BIRx8i+ tD6KhsgyJz0zQ3o6vpvvWFJsUPbV2v0xxH9O8fxSvbT/sg1/8HoOVJ6tihxuxOEHdwyt uHQc6gR1mlE/0F06vHlBdktjZqjy4kFHOna73YSI0hNXRvWOlHY6ZYTEGTseQKZaWWy9 L3N6UiFCuaT+T9c4i42K8lzpIxip/VadrB9ndMeN80YmDYe/jcUbqDy7oylLs5bz2/Yb Dgcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699274422; x=1699879222; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q/j5ZdORQp2c8s4IMJhl7QIq4MbRa4fgg20gEx4WXX8=; b=FG1bSa0sQr+ffZ9Mn0RQ4Tn2zxYf/TolcccJteqgjlTC2xpxQLT2SX8UJTdoiElqgC B089dsLyOxQaktCVviWGFIUwN33voZcdmoYIZ8qtJfJijycsN9GPFt1uiq6s4YhH6QPY UhGTDWgY8hjj9tPUrZTDNgMpuHPqB6aEcpDzXPdKLmkli8kqlAJR+8QDohJY7QFKyZ98 nGQgDOmqlJtAXc1aL8fnDLN0cI7IaczMAdtuzYOxvYTVhJNpujdhq1L2R5xeRuPuIG3D JWRAdq7qL8i2TPtx47evpOmYSHhEZDO4+8j8ClwgP8yD5ACVX8yi0r6O0Pk2QzxiHwyS bLjg== X-Gm-Message-State: AOJu0YxUs0kND6L+CNpnU976oDW3WpBG1OlPpomXlJ1ToOOFPHCQpk6/ M3/1AVktxqvTh2HhXf8qLiLN7fueEl5ixg== X-Google-Smtp-Source: AGHT+IGAz6Uu6354N+6w/E0T+0S1OgMe1mnBTFZ5yII6j2prs0Cc+X6f/ro/zCVVkp3kzBMo/wnpag== X-Received: by 2002:a17:906:7313:b0:9be:7de2:927c with SMTP id di19-20020a170906731300b009be7de2927cmr13174418ejc.70.1699274421947; Mon, 06 Nov 2023 04:40:21 -0800 (PST) Received: from skbuf ([188.26.57.160]) by smtp.gmail.com with ESMTPSA id fi3-20020a170906da0300b0099ce188be7fsm4060117ejb.3.2023.11.06.04.40.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 04:40:21 -0800 (PST) Date: Mon, 6 Nov 2023 14:40:19 +0200 From: Vladimir Oltean To: Linus Walleij Cc: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrew Lunn , linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v2 3/4] net: ethernet: cortina: Protect against oversized frames Message-ID: <20231106124019.ethagifngefgcihm@skbuf> References: <20231105-gemini-largeframe-fix-v2-0-cd3a5aa6c496@linaro.org> <20231105-gemini-largeframe-fix-v2-3-cd3a5aa6c496@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231105-gemini-largeframe-fix-v2-3-cd3a5aa6c496@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231106_044025_515935_D480333B X-CRM114-Status: GOOD ( 28.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Nov 05, 2023 at 09:57:25PM +0100, Linus Walleij wrote: > The max size of a transfer no matter the MTU is 64KB-1 so immediately > bail out if the skb exceeds that. > > The calling site tries to linearize the skbuff on error so return a > special error code -E2BIG to indicate that this will not work in > any way and bail out immediately if this happens. > > Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") > Signed-off-by: Linus Walleij > --- > drivers/net/ethernet/cortina/gemini.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c > index b21a94b4ab5c..576174a862a9 100644 > --- a/drivers/net/ethernet/cortina/gemini.c > +++ b/drivers/net/ethernet/cortina/gemini.c > @@ -1151,6 +1151,12 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, > if (skb->protocol == htons(ETH_P_8021Q)) > mtu += VLAN_HLEN; > > + if (skb->len > 65535) { > + /* The field for length is only 16 bits */ > + netdev_err(netdev, "%s: frame too big, max size 65535 bytes\n", __func__); > + return -E2BIG; > + } > + Prints in the packet data path are extremely discouraged, since if they trigger, they will spam your serial console and make it unusable. I see that the out_drop label already bumps a counter. That should be enough to signal there is a problem. > word1 = skb->len; > word3 = SOF_BIT; > > @@ -1232,6 +1238,7 @@ static netdev_tx_t gmac_start_xmit(struct sk_buff *skb, > struct gmac_txq *txq; > int txq_num, nfrags; > union dma_rwptr rw; > + int ret; > > if (skb->len >= 0x10000) > goto out_drop_free; Since you already have this test, does the newly introduced one make this redundant? Why not just change the limit here? > @@ -1269,7 +1276,11 @@ static netdev_tx_t gmac_start_xmit(struct sk_buff *skb, > } > } > > - if (gmac_map_tx_bufs(netdev, skb, txq, &w)) { > + ret = gmac_map_tx_bufs(netdev, skb, txq, &w); > + if (ret == -E2BIG) > + goto out_drop; Why out_drop and not out_drop_free? This handling will eventually cause an OOM. The fact that it didn't makes me suspect that you never actually hit this condition, because the network stack isn't delivering skbs larger than dev->mtu. Maybe net/core/pktgen.c doesn't take the MTU into consideration, I'm not completely sure there... > + if (ret) { > + /* Linearize and retry */ > if (skb_linearize(skb)) > goto out_drop; > > > -- > 2.34.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel