diff options
| -rw-r--r-- | CVE-2017-7477.patch | 73 | ||||
| -rw-r--r-- | kernel.spec | 6 |
2 files changed, 79 insertions, 0 deletions
diff --git a/CVE-2017-7477.patch b/CVE-2017-7477.patch new file mode 100644 index 000000000..6405614cc --- /dev/null +++ b/CVE-2017-7477.patch @@ -0,0 +1,73 @@ +From 4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" <Jason@zx2c4.com> +Date: Fri, 21 Apr 2017 23:14:48 +0200 +Subject: macsec: avoid heap overflow in skb_to_sgvec + +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> +--- + drivers/net/macsec.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c +index ff0a5ed..dbab05a 100644 +--- a/drivers/net/macsec.c ++++ b/drivers/net/macsec.c +@@ -2716,7 +2716,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) +-- +cgit v1.1 + diff --git a/kernel.spec b/kernel.spec index 79a08987c..48004edaf 100644 --- a/kernel.spec +++ b/kernel.spec @@ -614,6 +614,9 @@ Patch666: powerpc-prom-Increase-RMA-size-to-512MB.patch # CVE-2017-7645 rhbz 1443615 1443617 Patch667: CVE-2017-7645.patch +# CVE-2017-7477 rhbz 1445207 1445208 +Patch668: CVE-2017-7477.patch + # END OF PATCH DEFINITIONS %endif @@ -2178,6 +2181,9 @@ fi # # %changelog +* Tue Apr 25 2017 Justin M. Forbes <jforbes@fedoraproject.org> +- Fix CVE-2017-7477 (rhbz 1445207 1445208) + * Tue Apr 25 2017 Peter Robinson <pbrobinson@fedoraproject.org> - Minor ARM config cleanups |