* [dpdk-dev] [PATCH 1/2] net: fix underflow for checksum of invalid IPv4 packets
2018-12-17 15:50 [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Bruce Richardson
@ 2018-12-17 15:50 ` Bruce Richardson
2018-12-18 13:15 ` Hemant Agrawal
2018-12-17 15:50 ` [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum Bruce Richardson
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Bruce Richardson @ 2018-12-17 15:50 UTC (permalink / raw)
To: Olivier Matz, Keith Wiles; +Cc: dev, Bruce Richardson, stable
If we receive a packet with an invalid IP header, where the total packet
length is reported as less than the IP header length, we would end up
getting an underflow in the length subtraction. This could cause us to
checksum e.g. 4GB of data in the case where the result of the subtraction
was -1. We fix this by having the function return 0 - an invalid sum - when
the length is less than the header length.
CC: stable@dpdk.org
Fixes: af75078fece3 ("first public release")
Fixes: 6006818cfb26 ("net: new checksum functions")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/librte_net/rte_ip.h | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
index f2a8904a2..f9b909090 100644
--- a/lib/librte_net/rte_ip.h
+++ b/lib/librte_net/rte_ip.h
@@ -310,16 +310,20 @@ rte_ipv4_phdr_cksum(const struct ipv4_hdr *ipv4_hdr, uint64_t ol_flags)
* @param l4_hdr
* The pointer to the beginning of the L4 header.
* @return
- * The complemented checksum to set in the IP packet.
+ * The complemented checksum to set in the IP packet
+ * or 0 on error
*/
static inline uint16_t
rte_ipv4_udptcp_cksum(const struct ipv4_hdr *ipv4_hdr, const void *l4_hdr)
{
uint32_t cksum;
- uint32_t l4_len;
+ uint32_t l3_len, l4_len;
+
+ l3_len = rte_be_to_cpu_16(ipv4_hdr->total_length);
+ if (l3_len < sizeof(struct ipv4_hdr))
+ return 0;
- l4_len = (uint32_t)(rte_be_to_cpu_16(ipv4_hdr->total_length) -
- sizeof(struct ipv4_hdr));
+ l4_len = l3_len - sizeof(struct ipv4_hdr);
cksum = rte_raw_cksum(l4_hdr, l4_len);
cksum += rte_ipv4_phdr_cksum(ipv4_hdr, 0);
--
2.19.2
^ permalink raw reply [flat|nested] 10+ messages in thread
* [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum
2018-12-17 15:50 [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Bruce Richardson
2018-12-17 15:50 ` [dpdk-dev] [PATCH 1/2] net: fix underflow for checksum of invalid IPv4 packets Bruce Richardson
@ 2018-12-17 15:50 ` Bruce Richardson
2018-12-20 19:08 ` Ferruh Yigit
2018-12-20 19:33 ` Wiles, Keith
2018-12-18 12:50 ` [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Hemant Agrawal
2018-12-20 19:09 ` Ferruh Yigit
3 siblings, 2 replies; 10+ messages in thread
From: Bruce Richardson @ 2018-12-17 15:50 UTC (permalink / raw)
To: Olivier Matz, Keith Wiles; +Cc: dev, Bruce Richardson, stable
The checksum calculation APIs take only the packet headers pointers as
parameters, so they assume that the lengths reported in those headers are
correct. However, a malicious packet could claim to be far larger than it
is, so we need to check the header lengths in the driver before calling
the checksum API.
A better fix would be to allow the lengths to be passed into the API
function, but that would be an API break, so fixing in TAP driver for
now.
CC: stable@dpdk.org
Fixes: 8ae3023387e9 ("net/tap: add Rx/Tx checksum offload support")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
drivers/net/tap/rte_eth_tap.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 49afd38dd..0ec030bef 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -281,13 +281,27 @@ tap_verify_csum(struct rte_mbuf *mbuf)
l3_len = 4 * (iph->version_ihl & 0xf);
if (unlikely(l2_len + l3_len > rte_pktmbuf_data_len(mbuf)))
return;
+ /* check that the total length reported by header is not
+ * greater than the total received size
+ */
+ if (l2_len + rte_be_to_cpu_16(iph->total_length) >
+ rte_pktmbuf_data_len(mbuf))
+ return;
cksum = ~rte_raw_cksum(iph, l3_len);
mbuf->ol_flags |= cksum ?
PKT_RX_IP_CKSUM_BAD :
PKT_RX_IP_CKSUM_GOOD;
} else if (l3 == RTE_PTYPE_L3_IPV6) {
+ struct ipv6_hdr *iph = l3_hdr;
+
l3_len = sizeof(struct ipv6_hdr);
+ /* check that the total length reported by header is not
+ * greater than the total received size
+ */
+ if (l2_len + l3_len + rte_be_to_cpu_16(iph->payload_len) >
+ rte_pktmbuf_data_len(mbuf))
+ return;
} else {
/* IPv6 extensions are not supported */
return;
--
2.19.2
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum
2018-12-17 15:50 ` [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum Bruce Richardson
@ 2018-12-20 19:08 ` Ferruh Yigit
2018-12-20 19:33 ` Wiles, Keith
1 sibling, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2018-12-20 19:08 UTC (permalink / raw)
To: Bruce Richardson, Olivier Matz, Keith Wiles; +Cc: dev, stable
On 12/17/2018 3:50 PM, Bruce Richardson wrote:
> The checksum calculation APIs take only the packet headers pointers as
> parameters, so they assume that the lengths reported in those headers are
> correct. However, a malicious packet could claim to be far larger than it
> is, so we need to check the header lengths in the driver before calling
> the checksum API.
>
> A better fix would be to allow the lengths to be passed into the API
> function, but that would be an API break, so fixing in TAP driver for
> now.
>
> CC: stable@dpdk.org
> Fixes: 8ae3023387e9 ("net/tap: add Rx/Tx checksum offload support")
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum
2018-12-17 15:50 ` [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum Bruce Richardson
2018-12-20 19:08 ` Ferruh Yigit
@ 2018-12-20 19:33 ` Wiles, Keith
1 sibling, 0 replies; 10+ messages in thread
From: Wiles, Keith @ 2018-12-20 19:33 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: Olivier Matz, dev, stable
> On Dec 17, 2018, at 9:50 AM, Richardson, Bruce <bruce.richardson@intel.com> wrote:
>
> The checksum calculation APIs take only the packet headers pointers as
> parameters, so they assume that the lengths reported in those headers are
> correct. However, a malicious packet could claim to be far larger than it
> is, so we need to check the header lengths in the driver before calling
> the checksum API.
>
> A better fix would be to allow the lengths to be passed into the API
> function, but that would be an API break, so fixing in TAP driver for
> now.
>
> CC: stable@dpdk.org
> Fixes: 8ae3023387e9 ("net/tap: add Rx/Tx checksum offload support")
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> —
Acked-by: Keith Wiles <keith.wiles@intel.com>
Regards,
Keith
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum
2018-12-17 15:50 [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Bruce Richardson
2018-12-17 15:50 ` [dpdk-dev] [PATCH 1/2] net: fix underflow for checksum of invalid IPv4 packets Bruce Richardson
2018-12-17 15:50 ` [dpdk-dev] [PATCH 2/2] net/tap: add buffer overflow checks before checksum Bruce Richardson
@ 2018-12-18 12:50 ` Hemant Agrawal
2018-12-18 13:12 ` Richardson, Bruce
2018-12-20 19:09 ` Ferruh Yigit
3 siblings, 1 reply; 10+ messages in thread
From: Hemant Agrawal @ 2018-12-18 12:50 UTC (permalink / raw)
To: Bruce Richardson, Olivier Matz, Keith Wiles; +Cc: dev, Shreyansh Jain
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(-)
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum
2018-12-18 12:50 ` [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Hemant Agrawal
@ 2018-12-18 13:12 ` Richardson, Bruce
0 siblings, 0 replies; 10+ messages in thread
From: Richardson, Bruce @ 2018-12-18 13:12 UTC (permalink / raw)
To: Hemant Agrawal, Olivier Matz, Wiles, Keith; +Cc: dev, Shreyansh Jain
> -----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.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum
2018-12-17 15:50 [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Bruce Richardson
` (2 preceding siblings ...)
2018-12-18 12:50 ` [dpdk-dev] [PATCH 0/2] prevent out of bounds read with checksum Hemant Agrawal
@ 2018-12-20 19:09 ` Ferruh Yigit
3 siblings, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2018-12-20 19:09 UTC (permalink / raw)
To: Bruce Richardson, Olivier Matz, Keith Wiles
Cc: dev, Hemant Agrawal, Shreyansh Jain
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.
^ permalink raw reply [flat|nested] 10+ messages in thread