Currently we specify bzip2 compression for the main and extras
packages, but bzip2 is no longer permitted in artful and causes
a ftbfs. Switch to the default compression.
We call skb_cow_data, which is good anyway to ensure we can actually
modify the skb as such (another error from prior). Now that we have the
number of fragments required, we can safely allocate exactly that amount
of memory.
Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Jason A. Donenfeld <email address hidden>
Acked-by: Sabrina Dubroca <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
BugLink: http://bugs.launchpad.net/bugs/1685892
CVE-2017-7477
Acked-by: Stefan Bader <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
(cherry picked from commit 5294b83086cc1c35b4efeca03644cf9d12282e5b)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
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.)
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 <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
BugLink: http://bugs.launchpad.net/bugs/1685892
CVE-2017-7477
Acked-by: Stefan Bader <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
(cherry picked from commit 4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
39e0e4a...
by
Greg Kroah-Hartman <email address hidden>
Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.
Signed-off-by: Marek Szyprowski <email address hidden>
Reviewed-by: Christian König <email address hidden>
Acked-by: Daniel Vetter <email address hidden>
Signed-off-by: Sumit Semwal <email address hidden>
Link: http://patchwork.freedesktop<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
0d7746f...
by
=?utf-8?q?Horia_Geant=C4=83?= <email address hidden>
crypto: caam - fix invalid dereference in caam_rsa_init_tfm()
