- 19 May, 2014 40 commits
-
-
Salam Noureddine authored
[ Upstream commit e2401654 ] It is possible for the timer handlers to run after the call to ip_mc_down so use in_dev_put instead of __in_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the in_device being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by:
Salam Noureddine <noureddine@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Willy Tarreau <w@1wt.eu>
-
Salam Noureddine authored
[ Upstream commit 9260d3e1 ] It is possible for the timer handlers to run after the call to ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the inet6_dev being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by:
-
Chris Healy authored
[ Upstream commit 9a062013 ] This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested successfully on bridge diameters of ~200. Signed-off-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
-
Mariusz Ceier authored
[ Upstream commit d69e0f7e ] When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't, emac_dev_mcast_set should only enable RX of multicasts and reset MACHASH registers. It does this, but afterwards it either sets up multicast MACs filtering or disables RX of multicasts and resets MACHASH registers again, rendering IFF_ALLMULTI flag useless. This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set. Tested with kernel 2.6.37. Signed-off-by:
Mariusz Ceier <mceier+kernel@gmail.com> Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Salva Peir authored
[ Upstream commit 2b13d06c ] The wanxl_ioctl() code fails to initialize the two padding bytes of struct sync_serial_settings after the ->loopback member. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by:
Salva Peir <speiro@ai2.upv.es> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit d2dbbba7 ] IP/IPv6 fragmentation knows how to compute only TCP/UDP checksum. This causes problems if SCTP packets has to be fragmented and ipsummed has been set to PARTIAL due to checksum offload support. This condition can happen when retransmitting after MTU discover, or when INIT or other control chunks are larger then MTU. Check for the rare fragmentation condition in SCTP and use software checksum calculation in this case. CC: Fan Du <fan.du@windriver.com> Signed-off-by:
Vlad Yasevich <vyasevich@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Fan Du authored
[ Upstream commit 27127a82 ] igb/ixgbe have hardware sctp checksum support, when this feature is enabled and also IPsec is armed to protect sctp traffic, ugly things happened as xfrm_output checks CHECKSUM_PARTIAL to do checksum operation(sum every thing up and pack the 16bits result in the checksum field). The result is fail establishment of sctp communication. Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Fan Du <fan.du@windriver.com> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit e87b3998 ] dst->xfrm is conditionally defined. Provide accessor funtion that is always available. Signed-off-by:
-
Mathias Krause authored
[ Upstream commit 162b2bed ] The current code tests the length of the whole netlink message to be at least as long to fit a cn_msg. This is wrong as nlmsg_len includes the length of the netlink message header. Use nlmsg_len() instead to fix this "off-by-NLMSG_HDRLEN" size check. Cc: stable@vger.kernel.org # v2.6.14+ Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
-
Salva Peir authored
[ Upstream commit 96b34040 ] The fst_get_iface() code fails to initialize the two padding bytes of struct sync_serial_settings after the ->loopback member. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit c33a39c5 ] This patch fixes the calculation of the nlmsg size, by adding the missing nla_total_size(). Cc: Patrick McHardy <kaber@trash.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
[ Upstream commit fe119a05 ] This patch fixes the calculation of the nlmsg size, by adding the missing nla_total_size(). Signed-off-by:
-
Mathias Krause authored
[ Upstream commit e727ca82 ] Initialize event_data for all possible message types to prevent leaking kernel stack contents to userland (up to 20 bytes). Also set the flags member of the connector message to 0 to prevent leaking two more stack bytes this way. Cc: stable@vger.kernel.org # v2.6.15+ Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 1661bf36 ] We need to cap ->msg_namelen or it leads to a buffer overflow when we to the memcpy() in __audit_sockaddr(). It requires CAP_AUDIT_CONTROL to exploit this bug. The call tree is: ___sys_recvmsg() move_addr_to_user() audit_sockaddr() __audit_sockaddr() Reported-by:
Jri Aedla <juri.aedla@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 80ad1d61 ] commit 3ab5aee7 ("net: Convert TCP & DCCP hash tables to use RCU / hlist_nulls") incorrectly used sock_put() on TIMEWAIT sockets. We should instead use inet_twsk_put() Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit c52e2421 ] TCP stack should make sure it owns skbs before mangling them. We had various crashes using bnx2x, and it turned out gso_size was cleared right before bnx2x driver was populating TC descriptor of the _previous_ packet send. TCP stack can sometime retransmit packets that are still in Qdisc. Of course we could make bnx2x driver more robust (using ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack. We have identified two points where skb_unclone() was needed. This patch adds a WARN_ON_ONCE() to warn us if we missed another fix of this kind. Kudos to Neal for finding the root cause of this bug. Its visible using small MSS. Signed-off-by:
Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Eric Dumazet authored
commit 72a3effa ([NET]: Size listen hash tables using backlog hint) added a bug allowing inet6_synq_hash() to return an out of bound array index, because of u16 overflow. Bug can happen if system admins set net.core.somaxconn & net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536 Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Nikola Pajkovsky authored
https://bugzilla.redhat.com/1016108 64z is missing rhel6 commit 3af031a395c0 ("[crypto] algboss: Hold ref count on larval") which is causing cosmetic fuzz, because crypto_alg_get was move from crypto/api.c to crypto/internal.h. From: Herbert Xu <herbert@gondor.apana.org.au> [ upstream commit 77dbd7a9 ] crypto_larval_lookup should only return a larval if it created one. Any larval created by another entity must be processed through crypto_larval_wait before being returned. Otherwise this will lead to a larval being killed twice, which will most likely lead to a crash. Cc: stable@vger.kernel.org Reported-by:
Kees Cook <keescook@chromium.org> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Nikola Pajkovsky <npajkovs@redhat.com> Signed-off-by:
-
Kees Cook authored
commit 331415ff upstream Many drivers need to validate the characteristics of their HID report during initialization to avoid misusing the reports. This adds a common helper to perform validation of the report exisitng, the field existing, and the expected number of values within the field. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> [jmm: backported to 2.6.32] [wt: dev_err() in 2.6.32 instead of hid_err()] Signed-off-by:
-
Kees Cook authored
commit be67b68d upstream Defensively check that the field to be worked on is not NULL. Signed-off-by:
-
Kees Cook authored
commit 0fb6bd06 upstream A HID device could send a malicious output report that would cause the lg, lg3, and lg4 HID drivers to write beyond the output report allocation during an event, causing a heap overflow: [ 325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287 ... [ 414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten Additionally, while lg2 did correctly validate the report details, it was cleaned up and shortened. CVE-2013-2893 Signed-off-by:
-
Kees Cook authored
commit 412f3010 upstream A HID device could send a malicious output report that would cause the pantherlord HID driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 310.939483] usb 1-1: New USB device found, idVendor=0e8f, idProduct=0003 ... [ 315.980774] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2892 Signed-off-by:
-
Kees Cook authored
commit 78214e81 upstream The zeroplus HID driver was not checking the size of allocated values in fields it used. A HID device could send a malicious output report that would cause the driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005 ... [ 1466.243173] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2889 Signed-off-by:
-
Kees Cook authored
commit 43622021 upstream The "Report ID" field of a HID report is used to build indexes of reports. The kernel's index of these is limited to 256 entries, so any malicious device that sets a Report ID greater than 255 will trigger memory corruption on the host: [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878 [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b CVE-2013-2888 Signed-off-by:
-
Kees Cook authored
commit e0e29b68 upstream The module parameter "fwpostfix" is userspace controllable, unfiltered, and is used to define the firmware filename. b43_do_request_fw() populates ctx->errors[] on error, containing the firmware filename. b43err() parses its arguments as a format string. For systems with b43 hardware, this could lead to a uid-0 to ring-0 escalation. CVE-2013-2852 Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Kees Cook authored
commit ffc8b308 upstream Disk names may contain arbitrary strings, so they must not be interpreted as format strings. It seems that only md allows arbitrary strings to be used for disk names, but this could allow for a local memory corruption from uid 0 into ring 0. CVE-2013-2851 Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [jmm: Backport to 2.6.32] Signed-off-by:
-
Nicolas Dichtel authored
commit 85dfb745 upstream This field was left uninitialized. Some user daemons perform check against this field. Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Mathias Krause authored
commit a5cc68f3 upstream key_notify_sa_flush() and key_notify_policy_flush() miss to initialize the sadb_msg_reserved member of the broadcasted message and thereby leak 2 bytes of heap memory to listeners. Fix that. Signed-off-by:
-
Eric Dumazet authored
commit a963a37d upstream It's possible to use AF_INET6 sockets and to connect to an IPv4 destination. After this, socket dst cache is a pointer to a rtable, not rt6_info. ip6_sk_dst_check() should check the socket dst cache is IPv6, or else various corruptions/crashes can happen. Dave Jones can reproduce immediate crash with trinity -q -l off -n -c sendmsg -c connect With help from Hannes Frederic Sowa Reported-by:
Dave Jones <davej@redhat.com> Reported-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Vlad Yasevich authored
commit f2815633 upstream When SCTP is done processing a duplicate cookie chunk, it tries to delete a newly created association. For that, it has to set the right association for the side-effect processing to work. However, when it uses the SCTP_CMD_NEW_ASOC command, that performs more work then really needed (like hashing the associationa and assigning it an id) and there is no point to do that only to delete the association as a next step. In fact, it also creates an impossible condition where an association may be found by the getsockopt() call, and that association is empty. This causes a crash in some sctp getsockopts. The solution is rather simple. We simply use SCTP_CMD_SET_ASOC command that doesn't have all the overhead and does exactly what we need. Reported-by:
Karl Heiss <kheiss@gmail.com> Tested-by:
-
Max Matveev authored
commit d5ccd496 upstream Attempt to reduce the number of IP packets emitted in response to single SCTP packet (2e3216cd) introduced a complication - if a packet contains two COOKIE_ECHO chunks and nothing else then SCTP state machine corks the socket while processing first COOKIE_ECHO and then loses the association and forgets to uncork the socket. To deal with the issue add new SCTP command which can be used to set association explictly. Use this new command when processing second COOKIE_ECHO chunk to restore the context for SCTP state machine. Signed-off-by:
Max Matveev <makc@redhat.com> Signed-off-by:
-
Jonathan Salwan authored
commit 542db015 upstream In drivers/cdrom/cdrom.c mmc_ioctl_cdrom_read_data() allocates a memory area with kmalloc in line 2885. 2885 cgc->buffer = kmalloc(blocksize, GFP_KERNEL); 2886 if (cgc->buffer == NULL) 2887 return -ENOMEM; In line 2908 we can find the copy_to_user function: 2908 if (!ret && copy_to_user(arg, cgc->buffer, blocksize)) The cgc->buffer is never cleaned and initialized before this function. If ret = 0 with the previous basic block, it's possible to display some memory bytes in kernel space from userspace. When we read a block from the disk it normally fills the ->buffer but if the drive is malfunctioning there is a chance that it would only be partially filled. The result is an leak information to userspace. Signed-off-by:
-
Dan Carpenter authored
commit 627aad1c upstream The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
-
Dan Carpenter authored
commit 58f09e00 upstream. The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by:
-
Tetsuo Handa authored
If /proc/sys/kernel/core_pattern contains only "|", a NULL pointer dereference happens upon core dump because argv_split("") returns argv[0] == NULL. This bug was once fixed by commit 264b83c0 ("usermodehelper: check subprocess_info->path != NULL") but was by error reintroduced by commit 7f57cfa4 ("usermodehelper: kill the sub_info->path[0] check"). This bug seems to exist since 2.6.19 (the version which core dump to pipe was added). Depending on kernel version and config, some side effect might happen immediately after this oops (e.g. kernel panic with 2.6.32-358.18.1.el6). Signed-off-by:Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ian Abbott authored
Commit 677a3156 upstream. The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that currently writes (optionally) and reads back up to 5 "ports" consisting of 8 channels each. It reads up to 32 1-bit channels but can only read and write a whole port at once - it needs to handle up to 5 ports as the first channel it reads might not be aligned on a port boundary. It breaks out of the loop early if the next port it handles is beyond the final port on the card. It also breaks out early on the 5th port in the loop if the first channel was aligned. Unfortunately, it doesn't check that the current port it is dealing with belongs to the comedi subdevice the `insn_bits` handler is acting on. That's a bug. Redo the `for` loop to terminate after the final port belonging to the subdevice, changing the loop variable in the process to simplify things a bit. The `for` loop could now try and handle more than 5 ports if the subdevice has more than 40 channels, but the test `if (bitshift >= 32)` ensures it will break out early after 4 or 5 ports (depending on whether the first channel is aligned on a port boundary). (`bitshift` will be between -7 and 7 inclusive on the first iteration, increasing by 8 for each subsequent operation.) Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Jitendra Bhivare authored
Backported Alex Williamson's commit to 2.6.32.y http://git.kernel.org/linus/7b668357810ecb5fdda4418689d50f5d95aea6a8 It resolves the following assert when module is immediately reloaded. kernel BUG at drivers/pci/iova.c:155! <snip> Call Trace: [<ffffffff812645c5>] intel_alloc_iova+0xb5/0xe0 [<ffffffff8126725e>] __intel_map_single+0xbe/0x210 [<ffffffff812674ae>] intel_alloc_coherent+0xae/0x120 [<ffffffffa035f909>] be_queue_alloc+0xb9/0x140 [be2net] [<ffffffffa035fa5a>] be_rx_qs_create+0xca/0x370 [be2net] <snip> The issue is reproducible in 2.6.32.60 and also gets resolved by passing intel-iommu=strict to kernel. Signed-off-by:
Jitendra Bhivare <jitendra.bhivare@gmail.com> Signed-off-by:
-
Julian Anastasov authored
Fix CHECKSUM_PARTIAL handling. Tested for IPv4 TCP, UDP not tested because it needs network card with HW CSUM support. May be fixes problem where IPVS can not be used in virtual boxes. Problem appears with DNAT to local address when the local stack sends reply in CHECKSUM_PARTIAL mode. Fix tcp_dnat_handler and udp_dnat_handler to provide vaddr and daddr in right order (old and new IP) when calling tcp_partial_csum_update/udp_partial_csum_update (CHECKSUM_PARTIAL). Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> (cherry picked from commit 5bc9068e) Signed-off-by:
-
Willy Tarreau authored
syscall_trace_enter() and syscall_trace_leave() are only called from within asm code and do not need to be declared in the .c at all. Removing their reference fixes the build issue that was happening with gcc 4.7. Both Sven-Haegar Koch and Christoph Biedl confirmed this patch addresses their respective build issues. Cc: Sven-Haegar Koch <haegar@sdinet.de> Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by: -
Willy Tarreau authored
This reverts commit 4ed3bb08. As reported by Sven-Haegar Koch, this patch breaks make headers_check : CHECK include (0 files) CHECK include/asm (54 files) /home/haegar/src/2.6.32/linux/usr/include/asm/ptrace.h:5: included file 'linux/linkage.h' is not exported Signed-off-by:
-
