KEYS: add missing permission check for request_key() destination
When the request_key() syscall is not passed a destination keyring, it
links the requested key (if constructed) into the "default" request-key
keyring. This should require Write permission to the keyring. However,
there is actually no permission check.
This can be abused to add keys to any keyring to which only Search
permission is granted. This is because Search permission allows joining
the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
then will set the default request-key keyring to the session keyring.
Then, request_key() can be used to add keys to the keyring.
Both negatively and positively instantiated keys can be added using this
method. Adding negative keys is trivial. Adding a positive key is a
bit trickier. It requires that either /sbin/request-key positively
instantiates the key, or that another thread adds the key to the process
keyring at just the right time, such that request_key() misses it
initially but then finds it in construct_alloc_key().
Fix this bug by checking for Write permission to the keyring in
construct_get_dest_keyring() when the default keyring is being used.
We don't do the permission check for non-default keyrings because that
was already done by the earlier call to lookup_user_key(). Also,
request_key_and_link() is currently passed a 'struct key *' rather than
a key_ref_t, so the "possessed" bit is unavailable.
We also don't do the permission check for the "requestor keyring", to
continue to support the use case described by commit 8bbf4976b59f
("KEYS: Alter use of key instantiation link-to-keyring argument") where
/sbin/request-key recursively calls request_key() to add keys to the
original requestor's destination keyring. (I don't know of any users
who actually do that, though...)
Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key")
Cc: <email address hidden> # v2.6.13+
Signed-off-by: Eric Biggers <email address hidden>
Signed-off-by: David Howells <email address hidden>
CVE-2017-17807
(backported from commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b)
[kleber: adjust for context; fix a conflict due to a bogus trailing tab added
by a backport for Trusty; changed KEY_NEED_WRITE by KEY_WRITE on the call to
key_permission(), since they have been renamed later by upstream commit
f5895943d91b (KEYS: Move the flags representing required permission to
linux/key.h).]
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Detect when the mac length of a GSO packet is greater than the maximum
packet size (9700 bytes) and disable GSO.
Signed-off-by: Daniel Axtens <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit 8914a595110a6eca69a5e275b323f5d09e18f4f9)
Signed-off-by: Daniel Axtens <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
If you take a GSO skb, and split it into packets, will the MAC
length (L2 + L3 + L4 headers + payload) of those packets be small
enough to fit within a given length?
Move skb_gso_mac_seglen() to skbuff.h with other related functions
like skb_gso_network_seglen() so we can use it, and then create
skb_gso_validate_mac_len to do the full calculation.
Signed-off-by: Daniel Axtens <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit 2b16f048729bf35e6c28a40cbfad07239f9dcd90)
[nb: drop GSO_BY_FRAGS case as that isn't introduced until 4.8]
Signed-off-by: Daniel Axtens <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Add ndo_gso_check which a device can define to indicate whether is
is capable of doing GSO on a packet. This funciton would be called from
the stack to determine whether software GSO is needed to be done. A
driver should populate this function if it advertises GSO types for
which there are combinations that it wouldn't be able to handle. For
instance a device that performs UDP tunneling might only implement
support for transparent Ethernet bridging type of inner packets
or might have limitations on lengths of inner headers.
Signed-off-by: Tom Herbert <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit 04ffcb255f22a2a988ce7393e6e72f6eb3fcb7aa)
Signed-off-by: Daniel Axtens <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
918e619...
by
Kevin Cernekee <email address hidden>
The capability check in nfnetlink_rcv() verifies that the caller
has CAP_NET_ADMIN in the namespace that "owns" the netlink socket.
However, nfnl_cthelper_list is shared by all net namespaces on the
system. An unprivileged user can create user and net namespaces
in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()
check:
1ff41cb...
by
Srinivas Dasari <email address hidden>
cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE
CVE-2017-11089
Buffer overread may happen as nl80211_set_station() reads 4 bytes
from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
validating the size of data received when userspace sends less
than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
the buffer overread.
Fixes: 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access")
Cc: <email address hidden>
Signed-off-by: Srinivas Dasari <email address hidden>
Signed-off-by: Jouni Malinen <email address hidden>
Signed-off-by: Johannes Berg <email address hidden>
(cherry picked from commit 8feb69c7bd89513be80eb19198d48f154b254021)
Signed-off-by: Po-Hsu Lin <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
22aae65...
by
Mohamed Ghannam <email address hidden>
RDS: Heap OOB write in rds_message_alloc_sgs()
CVE-2018-5332
When args->nr_local is 0, nr_pages gets also 0 due some size
calculation via rds_rm_size(), which is later used to allocate
pages for DMA, this bug produces a heap Out-Of-Bound write access
to a specific memory region.
Signed-off-by: Mohamed Ghannam <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit c095508770aebf1b9218e77026e48345d719b17c)
Signed-off-by: Po-Hsu Lin <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
1deaf0c...
by
Nicholas Piggin <email address hidden>
powerpc: Do not call ppc_md.panic in fadump panic notifier
If fadump is not registered, and no other crash or debug handlers are
registered, the powerpc panic handler stops the guest before the
generic panic code can push out debug information to the console.
Currently, system reset injection causes the guest to silently stop.
Stop calling ppc_md.panic in the panic notifier. crash_fadump already
does rtas_os_term() to terminate the guest if fadump is registered.
Remove ppc_md.panic. Move fadump panic notifier into fadump code.
Signed-off-by: Nicholas Piggin <email address hidden>
Reviewed-by: Mahesh Salgaonkar <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
(backported from commit a3b2cb30f252b21a6f962e0dd107c8b897ca65e4)
[cascardo: context and setup_panic called from setup_{32,64}.c]
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Colin King <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
