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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DATE_IN_PAST_06_12, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABCBFC282DB for ; Mon, 21 Jan 2019 07:55:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6F63B20989 for ; Mon, 21 Jan 2019 07:55:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="AlWMtuej" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729066AbfAUHzd (ORCPT ); Mon, 21 Jan 2019 02:55:33 -0500 Received: from mail-yb1-f176.google.com ([209.85.219.176]:43868 "EHLO mail-yb1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728357AbfAUHza (ORCPT ); Mon, 21 Jan 2019 02:55:30 -0500 Received: by mail-yb1-f176.google.com with SMTP id e12so676839ybn.10 for ; Sun, 20 Jan 2019 23:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=rOqANX24C+dW3wPTQX038SGw6fvE+mKt+3O19kxKpKQ=; b=AlWMtuejDWFBHOLwRarQkc01zo70XI9TEws3gW3VYOrv9tXUQJK6Nqvf3ujEK0p7yO 8cm27SMX+eH+r7Y/BCyTntN4FauzBXsJWCZEU45+/dmlsyiF2MTpJgENki7NosThckaw hA74UHkMkziqTPrv5UEVb4TZDqq7urWgy+CKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rOqANX24C+dW3wPTQX038SGw6fvE+mKt+3O19kxKpKQ=; b=EAGPRAZ7txagNicZkQXQYookR7IykYDC6hcvrzUVtYYKXNedjTQIum/Mz71NROHDbr 5V5caOgvl8VkSmjyQnXuhjs0YHuomSQbfwkRVRtKZ0ASO/nbNFqKn2PT/XXC07CGifMd fBYC3jtDln3TCc9CqWskeq3bNsayVnj/5/u6D4m5wzO4bm+0dh1DxG8wxFsekuKb1GRs 0QFN1Dg1gmk3nYAefGuZW6tYCnoNzB87MHj/kvj7vuXiIbiyjqbMIkxP4L1705AGDIzd yyxR2g0EKzFFwLRbR1F8Qpm4aS1XAsjw5t5fIhwXwx4XsBg5Bp9VSfVpImVkzhCac6qx P4YQ== X-Gm-Message-State: AJcUukeSo/MDnzvfhtkMx45/tRu3nNxEBHi7NeBlJ5OylA3XIU8XQ5Ur mEMB1mCw32uZQeizptJUqBAs1+dslkaws+XPHQ4u+Wa6 X-Google-Smtp-Source: ALg8bN4v9hNILYHQAteCKCYqd50A1+6LQllJt3KS8jmBMaUjLzIzrio7EMflQLnqyZ7HlXiuOBG8IvnZVh1QyiOxhMw= X-Received: by 2002:a5b:28c:: with SMTP id x12mr10125630ybl.46.1548023228372; Sun, 20 Jan 2019 14:27:08 -0800 (PST) MIME-Version: 1.0 From: Michael Chan Date: Sun, 20 Jan 2019 14:26:57 -0800 Message-ID: Subject: Stack sends oversize UDP packet to the driver To: Netdev , David Miller Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org I've received a bug report of oversized UDP packets sent to the bnxt_en driver for transmission. There is no check for illegal length in the driver and it will send a corrupted BD to the NIC if the non-TSO length exceeds the maximum MTU supported by the driver. This ultimately causes the driver to hang. Looking a little deeper, it looks like the route of the SKB was initially to "lo" and therefore no fragmentation was done. And it looks like the route later got changed to the bnxt_en dev before transmission. The user was doing multiple VM reboots and the bad length was happening on the Linux host. I can add a length check in the driver to prevent this. But is there a better way to prevent this in the stack? Thanks.