| From 1c34ea323ad50dfa6426ffeb828550534b3387f9 Mon Sep 17 00:00:00 2001 |
| From: "Jason A. Donenfeld" <Jason@zx2c4.com> |
| Date: Fri, 21 Apr 2017 23:14:48 +0200 |
| Subject: [PATCH] macsec: avoid heap overflow in skb_to_sgvec |
| |
| commit 4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee upstream. |
| |
| While this may appear as a humdrum one line change, it's actually quite |
| important. An sk_buff stores data in three places: |
| |
| 1. A linear chunk of allocated memory in skb->data. This is the easiest |
| one to work with, but it precludes using scatterdata since the memory |
| must be linear. |
| 2. The array skb_shinfo(skb)->frags, which is of maximum length |
| MAX_SKB_FRAGS. This is nice for scattergather, since these fragments |
| can point to different pages. |
| 3. skb_shinfo(skb)->frag_list, which is a pointer to another sk_buff, |
| which in turn can have data in either (1) or (2). |
| |
| The first two are rather easy to deal with, since they're of a fixed |
| maximum length, while the third one is not, since there can be |
| potentially limitless chains of fragments. Fortunately dealing with |
| frag_list is opt-in for drivers, so drivers don't actually have to deal |
| with this mess. For whatever reason, macsec decided it wanted pain, and |
| so it explicitly specified NETIF_F_FRAGLIST. |
| |
| Because dealing with (1), (2), and (3) is insane, most users of sk_buff |
| doing any sort of crypto or paging operation calls a convenient function |
| called skb_to_sgvec (which happens to be recursive if (3) is in use!). |
| This takes a sk_buff as input, and writes into its output pointer an |
| array of scattergather list items. Sometimes people like to declare a |
| fixed size scattergather list on the stack; othertimes people like to |
| allocate a fixed size scattergather list on the heap. However, if you're |
| doing it in a fixed-size fashion, you really shouldn't be using |
| NETIF_F_FRAGLIST too (unless you're also ensuring the sk_buff and its |
| frag_list children arent't shared and then you check the number of |
| fragments in total required.) |
| |
| Macsec specifically does this: |
| |
| size += sizeof(struct scatterlist) * (MAX_SKB_FRAGS + 1); |
| tmp = kmalloc(size, GFP_ATOMIC); |
| *sg = (struct scatterlist *)(tmp + sg_offset); |
| ... |
| sg_init_table(sg, MAX_SKB_FRAGS + 1); |
| skb_to_sgvec(skb, sg, 0, skb->len); |
| |
| Specifying MAX_SKB_FRAGS + 1 is the right answer usually, but not if you're |
| using NETIF_F_FRAGLIST, in which case the call to skb_to_sgvec will |
| overflow the heap, and disaster ensues. |
| |
| Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> |
| Cc: stable@vger.kernel.org |
| Cc: security@kernel.org |
| Signed-off-by: David S. Miller <davem@davemloft.net> |
| Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> |
| |
| diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c |
| index b72ddc61eff8..c371596325dc 100644 |
| --- a/drivers/net/macsec.c |
| +++ b/drivers/net/macsec.c |
| @@ -2709,7 +2709,7 @@ static netdev_tx_t macsec_start_xmit(struct sk_buff *skb, |
| } |
| |
| #define MACSEC_FEATURES \ |
| - (NETIF_F_SG | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST) |
| + (NETIF_F_SG | NETIF_F_HIGHDMA) |
| static struct lock_class_key macsec_netdev_addr_lock_key; |
| |
| static int macsec_dev_init(struct net_device *dev) |
| -- |
| 2.12.0 |
| |