Message ID | 20181217155005.13457-1-bruce.richardson@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 756B11B736; Mon, 17 Dec 2018 16:50:38 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 96B0D1B6F7 for <dev@dpdk.org>; Mon, 17 Dec 2018 16:50:36 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 07:50:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,365,1539673200"; d="scan'208";a="130652856" Received: from silpixa00399126.ir.intel.com (HELO silpixa00399126.ger.corp.intel.com) ([10.237.222.236]) by fmsmga001.fm.intel.com with ESMTP; 17 Dec 2018 07:50:16 -0800 From: Bruce Richardson <bruce.richardson@intel.com> To: Olivier Matz <olivier.matz@6wind.com>, Keith Wiles <keith.wiles@intel.com> Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Shreyansh Jain <shreyansh.jain@nxp.com> Date: Mon, 17 Dec 2018 15:50:03 +0000 Message-Id: <20181217155005.13457-1-bruce.richardson@intel.com> X-Mailer: git-send-email 2.19.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
prevent out of bounds read with checksum
|
|
Message
Bruce Richardson
Dec. 17, 2018, 3:50 p.m. UTC
The functions for checksumming the packet payload don't perform bounds checks, and are used by the TAP driver which does not do any bounds checks on the incoming packet either. This means a packet received with an incorrect IP header can read beyond the end of the mbuf. In the worst case, where the length is specified as being smaller than the IPv4 header, 32-bit wrap-around on subtraction occurs, meaning that approx 4GB of memory will be read. To fix this, we can introduce a sanity check into the ipv4 function to ensure that underflow does not occur. Since the checksum function does not take the mbuf length as a parameter, we cannot check for overflow there, so we instead perform the checks in the TAP driver directly. Ideally, in a future release, all checksum functions should be modified to take a max buffer length parameter to fix this issue globally. NOTE: It appears that the dpaa driver also uses these functions, but from what I can see there, they are only used on TX, which means that there should be less need for parameter length checking, as the data does not come from an untrusted source. Perhaps maintainers, Hemant and Shreyansh, can confirm? CC: Hemant Agrawal <hemant.agrawal@nxp.com> CC: Shreyansh Jain <shreyansh.jain@nxp.com> Bruce Richardson (2): net: fix underflow for checksum of invalid IPv4 packets net/tap: add buffer overflow checks before checksum drivers/net/tap/rte_eth_tap.c | 14 ++++++++++++++ lib/librte_net/rte_ip.h | 12 ++++++++---- 2 files changed, 22 insertions(+), 4 deletions(-)
Comments
HI Bruce, On 17-Dec-18 9:20 PM, Bruce Richardson wrote: > The functions for checksumming the packet payload don't perform bounds > checks, and are used by the TAP driver which does not do any bounds checks > on the incoming packet either. This means a packet received with an > incorrect IP header can read beyond the end of the mbuf. > > In the worst case, where the length is specified as being smaller than the > IPv4 header, 32-bit wrap-around on subtraction occurs, meaning that approx > 4GB of memory will be read. > > To fix this, we can introduce a sanity check into the ipv4 function to > ensure that underflow does not occur. Since the checksum function does not > take the mbuf length as a parameter, we cannot check for overflow there, > so we instead perform the checks in the TAP driver directly. > > Ideally, in a future release, all checksum functions should be modified to > take a max buffer length parameter to fix this issue globally. > > NOTE: It appears that the dpaa driver also uses these functions, but from > what I can see there, they are only used on TX, which means that there > should be less need for parameter length checking, as the data does not > come from an untrusted source. Perhaps maintainers, Hemant and Shreyansh, > can confirm? In DPAA, we are using software based checksum calculation for self generated packets largely. They are mostly trust worthy unless someone is deliberately or mistakenly trying to send a corrupt packet. We will check, if we can also add some checks in DPAA driver in these legs without making performance impact for self generated packets. Regards, Hemant > > CC: Hemant Agrawal <hemant.agrawal@nxp.com> > CC: Shreyansh Jain <shreyansh.jain@nxp.com> > > Bruce Richardson (2): > net: fix underflow for checksum of invalid IPv4 packets > net/tap: add buffer overflow checks before checksum > > drivers/net/tap/rte_eth_tap.c | 14 ++++++++++++++ > lib/librte_net/rte_ip.h | 12 ++++++++---- > 2 files changed, 22 insertions(+), 4 deletions(-) >
> -----Original Message----- > From: Hemant Agrawal [mailto:hemant.agrawal@nxp.com] > Sent: Tuesday, December 18, 2018 12:50 PM > To: Richardson, Bruce <bruce.richardson@intel.com>; Olivier Matz > <olivier.matz@6wind.com>; Wiles, Keith <keith.wiles@intel.com> > Cc: dev@dpdk.org; Shreyansh Jain <shreyansh.jain@nxp.com> > Subject: Re: [dpdk-dev] [PATCH 0/2] prevent out of bounds read with > checksum > > HI Bruce, > > On 17-Dec-18 9:20 PM, Bruce Richardson wrote: > > The functions for checksumming the packet payload don't perform bounds > > checks, and are used by the TAP driver which does not do any bounds > > checks on the incoming packet either. This means a packet received > > with an incorrect IP header can read beyond the end of the mbuf. > > > > In the worst case, where the length is specified as being smaller than > > the > > IPv4 header, 32-bit wrap-around on subtraction occurs, meaning that > > approx 4GB of memory will be read. > > > > To fix this, we can introduce a sanity check into the ipv4 function to > > ensure that underflow does not occur. Since the checksum function does > > not take the mbuf length as a parameter, we cannot check for overflow > > there, so we instead perform the checks in the TAP driver directly. > > > > Ideally, in a future release, all checksum functions should be > > modified to take a max buffer length parameter to fix this issue > globally. > > > > NOTE: It appears that the dpaa driver also uses these functions, but > > from what I can see there, they are only used on TX, which means that > > there should be less need for parameter length checking, as the data > > does not come from an untrusted source. Perhaps maintainers, Hemant > > and Shreyansh, can confirm? > > In DPAA, we are using software based checksum calculation for self > generated packets largely. > > They are mostly trust worthy unless someone is deliberately or mistakenly > trying to send a corrupt packet. > > We will check, if we can also add some checks in DPAA driver in these legs > without making performance impact for self generated packets. > Right. Thanks for confirming it's not on RX path which would be the main risk. I would assume that data coming from the app should be trusted, unless the app is deliberately trying to crash itself. :-) (I didn't look to try and fix this in DPAA because of that assumption, but glad you are looking into it.)
On 12/17/2018 3:50 PM, Bruce Richardson wrote: > The functions for checksumming the packet payload don't perform bounds > checks, and are used by the TAP driver which does not do any bounds checks > on the incoming packet either. This means a packet received with an > incorrect IP header can read beyond the end of the mbuf. > > In the worst case, where the length is specified as being smaller than the > IPv4 header, 32-bit wrap-around on subtraction occurs, meaning that approx > 4GB of memory will be read. > > To fix this, we can introduce a sanity check into the ipv4 function to > ensure that underflow does not occur. Since the checksum function does not > take the mbuf length as a parameter, we cannot check for overflow there, > so we instead perform the checks in the TAP driver directly. > > Ideally, in a future release, all checksum functions should be modified to > take a max buffer length parameter to fix this issue globally. > > NOTE: It appears that the dpaa driver also uses these functions, but from > what I can see there, they are only used on TX, which means that there > should be less need for parameter length checking, as the data does not > come from an untrusted source. Perhaps maintainers, Hemant and Shreyansh, > can confirm? > > CC: Hemant Agrawal <hemant.agrawal@nxp.com> > CC: Shreyansh Jain <shreyansh.jain@nxp.com> > > Bruce Richardson (2): > net: fix underflow for checksum of invalid IPv4 packets > net/tap: add buffer overflow checks before checksum Series applied to dpdk-next-net/master, thanks.