link_info.str is a char array of size 60. Memory after the NULL
byte is not initialized. Sending the whole object out can cause
a leak.
Signed-off-by: Kangjie Lu <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit 5d2be1422e02ccd697ccfcd45c85b4a26e6178e2)
[ luis:
* change tipc_node_get_links() instead of tipc_nl_compat_link_dump()
see 357ebdbfca0b ("tipc: convert legacy nl link dump to nl compat")
* use strncpy() instead of nla_strlcpy() ]
CVE-2016-5243
BugLink: https://bugs.launchpad.net/bugs/1589036
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Brad Figg <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
cc1ee28...
by
Dan Carpenter <email address hidden>
KEYS: potential uninitialized variable
If __key_link_begin() failed then "edit" would be uninitialized. I've
added a check to fix that.
This allows a random user to crash the kernel, though it's quite
difficult to achieve. There are three ways it can be done as the user
would have to cause an error to occur in __key_link():
(1) Cause the kernel to run out of memory. In practice, this is difficult
to achieve without ENOMEM cropping up elsewhere and aborting the
attempt.
(2) Revoke the destination keyring between the keyring ID being looked up
and it being tested for revocation. In practice, this is difficult to
time correctly because the KEYCTL_REJECT function can only be used
from the request-key upcall process. Further, users can only make use
of what's in /sbin/request-key.conf, though this does including a
rejection debugging test - which means that the destination keyring
has to be the caller's session keyring in practice.
(3) Have just enough key quota available to create a key, a new session
keyring for the upcall and a link in the session keyring, but not then
sufficient quota to create a link in the nominated destination keyring
so that it fails with EDQUOT.
The bug can be triggered using option (3) above using something like the
following:
echo 80 >/proc/sys/kernel/keys/root_maxbytes
keyctl request2 user debug:fred negate @t
The above sets the quota to something much lower (80) to make the bug
easier to trigger, but this is dependent on the system. Note also that
the name of the keyring created contains a random number that may be
between 1 and 10 characters in size, so may throw the test off by
changing the amount of quota used.
Assuming the failure occurs, something like the following will be seen:
A qeth_card contains a napi_struct linked to the net_device during
device probing. This struct must be deleted when removing the qeth
device, otherwise Panic on oops can occur when qeth devices are
repeatedly removed and added.
Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
Cc: <email address hidden> # v2.6.37+
Signed-off-by: Ursula Braun <email address hidden>
Tested-by: Alexander Klein <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 7831b4ff0d926e0deeaabef9db8800ed069a2757)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Christopher Arges <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
