commit 3bd0d1ad14c3566107e391732e4df658b005ad67 Author: Willy Tarreau Date: Sat Dec 13 15:16:05 2014 +0100 Linux 2.6.32.65 Signed-off-by: Willy Tarreau commit 6eef90fc28562f7b4fb9f7f1661da08e90673e25 Author: Ben Hutchings Date: Sun Dec 7 19:57:36 2014 +0000 proc connector: Delete spurious memset in proc_exit_connector() Upstream commit e727ca82e0e9 ("proc connector: fix info leaks") changed many functions that don't exist in 2.6.32.y. When it was cherry-picked into 2.6.32.61, one extra memset() calls was inserted into proc_exit_connector(). This results in clearing the cpu field of exit events. Signed-off-by: Ben Hutchings Acked-by: Mathias Krause Signed-off-by: Willy Tarreau commit a99c4d9b097701ce465042c61d7eabf1ff26b4ae Author: Ben Hutchings Date: Sun Dec 7 19:57:15 2014 +0000 cciss: Fix misapplied "cciss: fix info leak in cciss_ioctl32_passthru()" Upstream commit 58f09e00ae09 was applied to the wrong function when cherry-picked for 2.6.32.61. Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit d22e4c7890e18c3c6565fca208a9ac910a6f8bf5 Author: Muthukumar Ratty Date: Sun Dec 7 19:56:48 2014 +0000 block: Fix blk_execute_rq_nowait() dead queue handling commit e81ca6fe85b77109a32489a5db82f575d51dfc98 upstream. If the queue is dead blk_execute_rq_nowait() doesn't invoke the done() callback function. That will result in blk_execute_rq() being stuck in wait_for_completion(). Avoid this by initializing rq->end_io to the done() callback before we check the queue state. Also, make sure the queue lock is held around the invocation of the done() callback. Found this through source code review. Signed-off-by: Muthukumar Ratty Signed-off-by: Bart Van Assche Reviewed-by: Tejun Heo Acked-by: Jens Axboe Signed-off-by: James Bottomley [bwh: Backported to 2.6.32: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 3b77fc36cefaacba19a48db43ab3b8dc57cbfc1b Author: Tejun Heo Date: Sun Dec 7 19:55:49 2014 +0000 block: add missing blk_queue_dead() checks commit 8ba61435d73f2274e12d4d823fde06735e8f6a54 upstream. blk_insert_cloned_request(), blk_execute_rq_nowait() and blk_flush_plug_list() either didn't check whether the queue was dead or did it without holding queue_lock. Update them so that dead state is checked while holding queue_lock. AFAICS, this plugs all holes (requeue doesn't matter as the request is transitioning atomically from in_flight to queued). Signed-off-by: Tejun Heo Signed-off-by: Jens Axboe [bwh: Backported to 2.6.32: - Drop inapplicable changes to queue_unplugged() and blk_flush_plug_list() - We don't have blk_queue_dead() so open-code it - Adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit d49465185ef41bea43666e349b72b6d1e1fbd296 Author: Ben Hutchings Date: Sun Dec 7 20:00:27 2014 +0000 md/raid6: Fix misapplied backport in 2.6.32.64 Upstream commit 9c4bdf697c39 ("md/raid6: avoid data corruption during recovery of double-degraded RAID6") changes handle_stripe(), but we have separate functions for RAID5 and RAID6 and need to apply the change to handle_stripe6(). When cherry-picked, the change was wrongly applied to handle_stripe5(). Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 7185a7199b3e6540e72c718db0ad1a91676e37d0 Author: Ben Hutchings Date: Sun Dec 7 19:59:23 2014 +0000 sctp: Fix double-free introduced by bad backport in 2.6.32.62 One deletion was omitted from the backport of upstream commit c485658bae87 ("net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk"). Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 04b872de72b9ddc84d4a0feae477ca7a484af9c1 Author: Matthijs Kooijman Date: Sun Dec 7 19:58:41 2014 +0000 vlan: Don't propagate flag changes on down interfaces. commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7 upstream. When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC flags are cleared or set on the underlying interface. So, if these flags are changed on a vlan interface that is not up, the flags underlying interface might be set or cleared twice. Only propagating flag changes when a device is up makes sure this does not happen. It also makes sure that an underlying device is not set to promiscuous or allmulti mode for a vlan device that is down. Signed-off-by: Matthijs Kooijman Signed-off-by: David S. Miller [bwh: This is a dependency of commit d2615bf45069 ("net: core: Always propagate flag changes to interfaces"), already backported in 2.6.32.62] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 44023d2f627574ac8a22c2ede35b7f8528bc7912 Author: Dan Carpenter Date: Mon Nov 24 12:16:11 2014 +0000 ttusb-dec: buffer overflow in ioctl commit dc0ab1ddeb0c5f5eb3f37a72eadb394792b3c40d upstream We need to add a limit check here so we don't overflow the buffer. Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab (backported from commit f2e323ec96077642d397bb1c355def536d489d16) CVE-2014-8884 BugLink: http://bugs.launchpad.net/bugs/1395187 Signed-off-by: Luis Henriques Acked-by: Andy Whitcroft Signed-off-by: Andy Whitcroft Acked-by: Stefan Bader Signed-off-by: Willy Tarreau commit ed99f57702c1173908edfc079abb54de412117b0 Author: Johannes Berg Date: Mon Nov 24 12:16:18 2014 +0000 mac80211: fix fragmentation code, particularly for encryption commit a722a419815ed203b519151f9556859ff256638b upstream The "new" fragmentation code (since my rewrite almost 5 years ago) erroneously sets skb->len rather than using skb_trim() to adjust the length of the first fragment after copying out all the others. This leaves the skb tail pointer pointing to after where the data originally ended, and thus causes the encryption MIC to be written at that point, rather than where it belongs: immediately after the data. The impact of this is that if software encryption is done, then a) encryption doesn't work for the first fragment, the connection becomes unusable as the first fragment will never be properly verified at the receiver, the MIC is practically guaranteed to be wrong b) we leak up to 8 bytes of plaintext (!) of the packet out into the air This is only mitigated by the fact that many devices are capable of doing encryption in hardware, in which case this can't happen as the tail pointer is irrelevant in that case. Additionally, fragmentation is not used very frequently and would normally have to be configured manually. Fix this by using skb_trim() properly. Cc: stable@vger.kernel.org Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation") Reported-by: Jouni Malinen Signed-off-by: Johannes Berg (backported from commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f) CVE-2014-8709 BugLink: http://bugs.launchpad.net/bugs/1392013 Signed-off-by: Luis Henriques Acked-by: Andy Whitcroft Acked-by: Stefan Bader Signed-off-by: Andy Whitcroft Signed-off-by: Willy Tarreau commit 4e5bfd776f9f8f9add60e9eb1a9d7042a48ae2b5 Author: Daniel Borkmann Date: Mon Nov 24 12:16:01 2014 +0000 net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet commit a6e1af6f5e9e75095ae1b004f6f00082e5fc4d2d upstream An SCTP server doing ASCONF will panic on malformed INIT ping-of-death in the form of: ------------ INIT[PARAM: SET_PRIMARY_IP] ------------> While the INIT chunk parameter verification dissects through many things in order to detect malformed input, it misses to actually check parameters inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary IP address' parameter in ASCONF, which has as a subparameter an address parameter. So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0 and thus sctp_get_af_specific() returns NULL, too, which we then happily dereference unconditionally through af->from_addr_param(). The trace for the log: BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 IP: [] sctp_process_init+0x492/0x990 [sctp] PGD 0 Oops: 0000 [#1] SMP [...] Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs RIP: 0010:[] [] sctp_process_init+0x492/0x990 [sctp] [...] Call Trace: [] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp] [] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp] [] sctp_do_sm+0x71/0x1210 [sctp] [] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp] [] sctp_endpoint_bh_rcv+0x116/0x230 [sctp] [] sctp_inq_push+0x56/0x80 [sctp] [] sctp_rcv+0x982/0xa10 [sctp] [] ? ipt_local_in_hook+0x23/0x28 [iptable_filter] [] ? nf_iterate+0x69/0xb0 [] ? ip_local_deliver_finish+0x0/0x2d0 [] ? nf_hook_slow+0x76/0x120 [] ? ip_local_deliver_finish+0x0/0x2d0 [...] A minimal way to address this is to check for NULL as we do on all other such occasions where we know sctp_get_af_specific() could possibly return with NULL. Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT") Signed-off-by: Daniel Borkmann Cc: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller (cherry picked from commit e40607cbe270a9e8360907cb1e62ddf0736e4864) CVE-2014-7841 BugLink: http://bugs.launchpad.net/bugs/1392820 Signed-off-by: Luis Henriques Acked-by: Andy Whitcroft Acked-by: Stefan Bader Signed-off-by: Andy Whitcroft Signed-off-by: Willy Tarreau commit 0973cb310090b529264d92fd4f201de1e316c933 Author: Jan Kara Date: Tue Sep 23 14:39:05 2014 +0100 udf: Avoid infinite loop when processing indirect ICBs commit 541d302ee5c46336cbad333222bc278b76cc1c42 upstream We did not implement any bound on number of indirect ICBs we follow when loading inode. Thus corrupted medium could cause kernel to go into an infinite loop, possibly causing a stack overflow. Fix the possible stack overflow by removing recursion from __udf_read_inode() and limit number of indirect ICBs we follow to avoid infinite loops. Signed-off-by: Jan Kara (back ported from commit c03aa9f6e1f938618e6db2e23afef0574efeeb65) [ luis: adjusted context and replaced udf_err() by printk() ] CVE-2014-6410 BugLink: http://bugs.launchpad.net/bugs/1370042 Signed-off-by: Luis Henriques Signed-off-by: Tim Gardner Signed-off-by: Willy Tarreau commit b77b8578b6924ffbc77279b7856ee1a77232ef5a Author: Daniel Borkmann Date: Tue Nov 11 17:49:30 2014 +0000 net: sctp: fix remote memory pressure from excessive queueing commit b2d33ef40de7161c23032106284959ae75bdf3cd upstream This scenario is not limited to ASCONF, just taken as one example triggering the issue. When receiving ASCONF probes in the form of ... -------------- INIT[ASCONF; ASCONF_ACK] -------------> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------ -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- ---- ASCONF_a; [ASCONF_b; ...; ASCONF_n;] JUNK ------> [...] ---- ASCONF_m; [ASCONF_o; ...; ASCONF_z;] JUNK ------> ... where ASCONF_a, ASCONF_b, ..., ASCONF_z are good-formed ASCONFs and have increasing serial numbers, we process such ASCONF chunk(s) marked with !end_of_packet and !singleton, since we have not yet reached the SCTP packet end. SCTP does only do verification on a chunk by chunk basis, as an SCTP packet is nothing more than just a container of a stream of chunks which it eats up one by one. We could run into the case that we receive a packet with a malformed tail, above marked as trailing JUNK. All previous chunks are here goodformed, so the stack will eat up all previous chunks up to this point. In case JUNK does not fit into a chunk header and there are no more other chunks in the input queue, or in case JUNK contains a garbage chunk header, but the encoded chunk length would exceed the skb tail, or we came here from an entirely different scenario and the chunk has pdiscard=1 mark (without having had a flush point), it will happen, that we will excessively queue up the association's output queue (a correct final chunk may then turn it into a response flood when flushing the queue ;)): I ran a simple script with incremental ASCONF serial numbers and could see the server side consuming excessive amount of RAM [before/after: up to 2GB and more]. The issue at heart is that the chunk train basically ends with !end_of_packet and !singleton markers and since commit 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") therefore preventing an output queue flush point in sctp_do_sm() -> sctp_cmd_interpreter() on the input chunk (chunk = event_arg) even though local_cork is set, but its precedence has changed since then. In the normal case, the last chunk with end_of_packet=1 would trigger the queue flush to accommodate possible outgoing bundling. In the input queue, sctp_inq_pop() seems to do the right thing in terms of discarding invalid chunks. So, above JUNK will not enter the state machine and instead be released and exit the sctp_assoc_bh_rcv() chunk processing loop. It's simply the flush point being missing at loop exit. Adding a try-flush approach on the output queue might not work as the underlying infrastructure might be long gone at this point due to the side-effect interpreter run. One possibility, albeit a bit of a kludge, would be to defer invalid chunk freeing into the state machine in order to possibly trigger packet discards and thus indirectly a queue flush on error. It would surely be better to discard chunks as in the current, perhaps better controlled environment, but going back and forth, it's simply architecturally not possible. I tried various trailing JUNK attack cases and it seems to look good now. Joint work with Vlad Yasevich. Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") Signed-off-by: Daniel Borkmann Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller (cherry picked from commit 26b87c7881006311828bb0ab271a551a62dcceb4) CVE-2014-3688 BugLink: http://bugs.launchpad.net/bugs/1386393 Signed-off-by: Luis Henriques Acked-by: Andy Whitcroft Signed-off-by: Brad Figg Signed-off-by: Willy Tarreau commit eec4c8182fd04911e474d43593581fcc95a03833 Author: Daniel Borkmann Date: Tue Nov 11 17:49:24 2014 +0000 net: sctp: fix panic on duplicate ASCONF chunks commit 12b18fdbbda747ad22a7684413a6559b681e503c upstream When receiving a e.g. semi-good formed connection scan in the form of ... -------------- INIT[ASCONF; ASCONF_ACK] -------------> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------ -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- ---------------- ASCONF_a; ASCONF_b -----------------> ... where ASCONF_a equals ASCONF_b chunk (at least both serials need to be equal), we panic an SCTP server! The problem is that good-formed ASCONF chunks that we reply with ASCONF_ACK chunks are cached per serial. Thus, when we receive a same ASCONF chunk twice (e.g. through a lost ASCONF_ACK), we do not need to process them again on the server side (that was the idea, also proposed in the RFC). Instead, we know it was cached and we just resend the cached chunk instead. So far, so good. Where things get nasty is in SCTP's side effect interpreter, that is, sctp_cmd_interpreter(): While incoming ASCONF_a (chunk = event_arg) is being marked !end_of_packet and !singleton, and we have an association context, we do not flush the outqueue the first time after processing the ASCONF_ACK singleton chunk via SCTP_CMD_REPLY. Instead, we keep it queued up, although we set local_cork to 1. Commit 2e3216cd54b1 changed the precedence, so that as long as we get bundled, incoming chunks we try possible bundling on outgoing queue as well. Before this commit, we would just flush the output queue. Now, while ASCONF_a's ASCONF_ACK sits in the corked outq, we continue to process the same ASCONF_b chunk from the packet. As we have cached the previous ASCONF_ACK, we find it, grab it and do another SCTP_CMD_REPLY command on it. So, effectively, we rip the chunk->list pointers and requeue the same ASCONF_ACK chunk another time. Since we process ASCONF_b, it's correctly marked with end_of_packet and we enforce an uncork, and thus flush, thus crashing the kernel. Fix it by testing if the ASCONF_ACK is currently pending and if that is the case, do not requeue it. When flushing the output queue we may relink the chunk for preparing an outgoing packet, but eventually unlink it when it's copied into the skb right before transmission. Joint work with Vlad Yasevich. Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") Signed-off-by: Daniel Borkmann Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller (cherry picked from commit b69040d8e39f20d5215a03502a8e8b4c6ab78395) CVE-2014-3687 BugLink: http://bugs.launchpad.net/bugs/1386392 Signed-off-by: Luis Henriques Acked-by: Andy Whitcroft Signed-off-by: Brad Figg Signed-off-by: Willy Tarreau commit 476b176f150a039d7f65784637295ae016e74d6d Author: James Forshaw Date: Wed Sep 17 10:21:53 2014 +0100 USB: whiteheat: Added bounds checking for bulk command response commit c5fd4126151855330280ea9382684980afcfdd03 upstream This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw Cc: stable Signed-off-by: Greg Kroah-Hartman (backported from commit 6817ae225cd650fb1c3295d769298c38b1eba818) CVE-2014-3185 BugLink: http://bugs.launchpad.net/bugs/1370036 Signed-off-by: Luis Henriques Signed-off-by: Tim Gardner Signed-off-by: Willy Tarreau commit 0a592dacc6f5d469d7f5409b06990d4a2ce1b9c5 Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:32 2014 +0200 ALSA: control: Fix replacing user controls (commit 82262a46627bebb0febcc26664746c25cef08563 upstream) There are two issues with the current implementation for replacing user controls. The first is that the code does not check if the control is actually a user control and neither does it check if the control is owned by the process that tries to remove it. That allows userspace applications to remove arbitrary controls, which can cause a user after free if a for example a driver does not expect a control to be removed from under its feed. The second issue is that on one hand when a control is replaced the user_ctl_count limit is not checked and on the other hand the user_ctl_count is increased (even though the number of user controls does not change). This allows userspace, once the user_ctl_count limit as been reached, to repeatedly replace a control until user_ctl_count overflows. Once that happens new controls can be added effectively bypassing the user_ctl_count limit. Both issues can be fixed by instead of open-coding the removal of the control that is to be replaced to use snd_ctl_remove_user_ctl(). This function does proper permission checks as well as decrements user_ctl_count after the control has been removed. Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at beginning of the function if the control already exists is removed. This is not a problem though since the check is quite useless, because the lock that is protecting the control list is released between the check and before adding the new control to the list, which means that it is possible that a different control with the same settings is added to the list after the check. Luckily there is another check that is done while holding the lock in snd_ctl_add(), so we'll rely on that to make sure that the same control is not added twice. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Cc: Signed-off-by: Takashi Iwai [wt: fixes CVE-2014-4654 & CVE-2014-4655] Signed-off-by: Willy Tarreau commit c99bd4fceec6135a31f95de4716a42e2064909bf Author: Lars-Peter Clausen Date: Wed Jun 18 13:32:33 2014 +0200 ALSA: control: Don't access controls outside of protected regions (commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream) A control that is visible on the card->controls list can be freed at any time. This means we must not access any of its memory while not holding the controls_rw_lock. Otherwise we risk a use after free access. Signed-off-by: Lars-Peter Clausen Acked-by: Jaroslav Kysela Cc: Signed-off-by: Takashi Iwai [wt: fixes CVE-2014-4653] Signed-off-by: Willy Tarreau commit eb406993c7b80c68b053c5d3d6431f4b8d0560eb Author: Sasha Levin Date: Mon Jul 14 17:02:31 2014 -0700 net/l2tp: don't fall back on UDP [get|set]sockopt (commit 3cf521f7dc87c031617fd47e4b7aa2593c2f3daf upstream) The l2tp [get|set]sockopt() code has fallen back to the UDP functions for socket option levels != SOL_PPPOL2TP since day one, but that has never actually worked, since the l2tp socket isn't an inet socket. As David Miller points out: "If we wanted this to work, it'd have to look up the tunnel and then use tunnel->sk, but I wonder how useful that would be" Since this can never have worked so nobody could possibly have depended on that functionality, just remove the broken code and return -EINVAL. Reported-by: Sasha Levin Acked-by: James Chapman Acked-by: David Miller Cc: Phil Turnbull Cc: Vegard Nossum Cc: Willy Tarreau Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds [geissert: adjust file paths and context for 2.6.32] [wt: fixes CVE-2014-4943] Signed-off-by: Willy Tarreau commit 1f4495612dce156f9ca8a33d8b9de134f9329be2 Author: Andy Lutomirski Date: Sat Nov 22 18:00:33 2014 -0800 x86_64, traps: Rework bad_iret It's possible for iretq to userspace to fail. This can happen because of a bad CS, SS, or RIP. Historically, we've handled it by fixing up an exception from iretq to land at bad_iret, which pretends that the failed iret frame was really the hardware part of #GP(0) from userspace. To make this work, there's an extra fixup to fudge the gs base into a usable state. This is suboptimal because it loses the original exception. It's also buggy because there's no guarantee that we were on the kernel stack to begin with. For example, if the failing iret happened on return from an NMI, then we'll end up executing general_protection on the NMI stack. This is bad for several reasons, the most immediate of which is that general_protection, as a non-paranoid idtentry, will try to deliver signals and/or schedule from the wrong stack. This patch throws out bad_iret entirely. As a replacement, it augments the existing swapgs fudge into a full-blown iret fixup, mostly written in C. It's should be clearer and more correct. Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds (cherry picked from commit b645af2d5905c4e32399005b867987919cbfc3ae) [wt: notes for backport to 2.6.32: - _ASM_EXTABLE was open-coded. - removed unneeded CFI_ENDPROC - removed __visible (introduced in 2.6.37-rc1, not needed here) /wt] Signed-off-by: Willy Tarreau commit 70443551ff6483f8d7a6f3457504e12c03270099 Author: Andy Lutomirski Date: Sat Nov 22 18:00:31 2014 -0800 x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C There's nothing special enough about the espfix64 double fault fixup to justify writing it in assembly. Move it to C. This also fixes a bug: if the double fault came from an IST stack, the old asm code would return to a partially uninitialized stack frame. Fixes: 3891a04aafd668686239349ea58f3314ea2af86b Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds (cherry picked from commit af726f21ed8af2cdaa4e93098dc211521218ae65) [wt: backport notes for 2.6.32 : - Adaptations to entry_64.S in declaration of do_double_fault. - no exception_enter() in 2.6.32. Seems to be only for context tracking. /wt] Signed-off-by: Willy Tarreau commit 0e62192bf1688f67d5a6cc1447c94319c320a09a Author: Andy Lutomirski Date: Sat Nov 22 18:00:32 2014 -0800 x86_64, traps: Stop using IST for #SS On a 32-bit kernel, this has no effect, since there are no IST stacks. On a 64-bit kernel, #SS can only happen in user code, on a failed iret to user space, a canonical violation on access via RSP or RBP, or a genuine stack segment violation in 32-bit kernel code. The first two cases don't need IST, and the latter two cases are unlikely fatal bugs, and promoting them to double faults would be fine. This fixes a bug in which the espfix64 code mishandles a stack segment violation. This saves 4k of memory per CPU and a tiny bit of code. Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds (cherry picked from commit 6f442be2fb22be02cafa606f1769fa1e6f894441) [wt: no CONFIG_TRACING on 2.6.32, Fixes CVE-2014-9090] Signed-off-by: Willy Tarreau commit f890caed2119e22e108ee7726fcb57255096f918 Author: Boris Ostrovsky Date: Wed Jul 9 13:18:18 2014 -0400 x86/espfix/xen: Fix allocation of pages for paravirt page tables commit 8762e5092828c4dc0f49da5a47a644c670df77f3 upstream. init_espfix_ap() is currently off by one level when informing hypervisor that allocated pages will be used for ministacks' page tables. The most immediate effect of this on a PV guest is that if 'stack_page = __get_free_page()' returns a non-zeroed-out page the hypervisor will refuse to use it for a page table (which it shouldn't be anyway). This will result in warnings by both Xen and Linux. More importantly, a subsequent write to that page (again, by a PV guest) is likely to result in fatal page fault. Signed-off-by: Boris Ostrovsky Link: http://lkml.kernel.org/r/1404926298-5565-1-git-send-email-boris.ostrovsky@oracle.com Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 060e7f67c88ebbcf8745505c7ccf44c53601f7de) Signed-off-by: Willy Tarreau commit 841d5934d7a249f4abf604976afda9e0b9c0f3bd Author: Andy Lutomirski Date: Wed Jul 23 08:34:11 2014 -0700 x86_64/entry/xen: Do not invoke espfix64 on Xen commit 7209a75d2009dbf7745e2fd354abf25c3deb3ca3 upstream. This moves the espfix64 logic into native_iret. To make this work, it gets rid of the native patch for INTERRUPT_RETURN: INTERRUPT_RETURN on native kernels is now 'jmp native_iret'. This changes the 16-bit SS behavior on Xen from OOPSing to leaking some bits of the Xen hypervisor's RSP (I think). [ hpa: this is a nonzero cost on native, but probably not enough to measure. Xen needs to fix this in their own code, probably doing something equivalent to espfix64. ] Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/7b8f1d8ef6597cb16ae004a43c56980a7de3cf94.1406129132.git.luto@amacapital.net Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 8ba19cd8c351e16b6be4caca9338d19b0cb8eaa4) Signed-off-by: Willy Tarreau commit 0a6feab8c3d56488549ef15fdeba4ce20dc4b8a9 Author: H. Peter Anvin Date: Sun May 4 10:36:22 2014 -0700 x86, espfix: Make it possible to disable 16-bit support commit 34273f41d57ee8d854dcd2a1d754cbb546cb548f upstream. Embedded systems, which may be very memory-size-sensitive, are extremely unlikely to ever encounter any 16-bit software, so make it a CONFIG_EXPERT option to turn off support for any 16-bit software whatsoever. Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 70d87cbbd92a3611655b39003176ee1033796bf7) [wt: backport notes for 2.6.32 : - Fixed arch/x86/kernel/ldt.c (no IS_ENABLED on 2.6.32). - No CONFIG_EXPERT condition in 2.6.32. /wt] Signed-off-by: Willy Tarreau commit 6e4bcdb55bf0a18b3dbbd6b3bc4d4526133fcd0c Author: H. Peter Anvin Date: Sun May 4 10:00:49 2014 -0700 x86, espfix: Make espfix64 a Kconfig option, fix UML commit 197725de65477bc8509b41388157c1a2283542bb upstream. Make espfix64 a hidden Kconfig option. This fixes the x86-64 UML build which had broken due to the non-existence of init_espfix_bsp() in UML: since UML uses its own Kconfig, this option does not appear in the UML build. This also makes it possible to make support for 16-bit segments a configuration option, for the people who want to minimize the size of the kernel. Reported-by: Ingo Molnar Signed-off-by: H. Peter Anvin Cc: Richard Weinberger Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit da22646d97b7322c757f3a7a21805a3475fed231) Signed-off-by: Willy Tarreau commit 27285e480fc99430c0be2063043bb7e0e1fdbc25 Author: H. Peter Anvin Date: Fri May 2 11:33:51 2014 -0700 x86, espfix: Fix broken header guard commit 20b68535cd27183ebd3651ff313afb2b97dac941 upstream. Header guard is #ifndef, not #ifdef... Reported-by: Fengguang Wu Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 7d4a9eabfe6c7fed70941aceb3b20bf393652bcb) Signed-off-by: Willy Tarreau commit 2ea4512fede6d3027ae54ad3393cffb378ee43bd Author: H. Peter Anvin Date: Thu May 1 14:12:23 2014 -0700 x86, espfix: Move espfix definitions into a separate header file commit e1fe9ed8d2a4937510d0d60e20705035c2609aea upstream. Sparse warns that the percpu variables aren't declared before they are defined. Rather than hacking around it, move espfix definitions into a proper header file. Reported-by: Fengguang Wu Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 62358ee6bb9d3d9dd4761d39ac0e1ede9ba70b0e) [wt: using DECLARE_PER_CPU instead of DECLARE_PER_CPU_READ_MOSTLY] Signed-off-by: Willy Tarreau commit 36102caaf7d9000fb04592163ffc623d834cc540 Author: H. Peter Anvin Date: Tue Apr 29 16:46:09 2014 -0700 x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack commit 3891a04aafd668686239349ea58f3314ea2af86b upstream. The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. This causes some 16-bit software to break, but it also leaks kernel state to user space. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 64-bit mode. In checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels we "solved" this by forbidding 16-bit segments on 64-bit kernels, with the logic that 16-bit support is crippled on 64-bit kernels anyway (no V86 support), but it turns out that people are doing stuff like running old Win16 binaries under Wine and expect it to work. This works around this by creating percpu "ministacks", each of which is mapped 2^16 times 64K apart. When we detect that the return SS is on the LDT, we copy the IRET frame to the ministack and use the relevant alias to return to userspace. The ministacks are mapped readonly, so if IRET faults we promote #GP to #DF which is an IST vector and thus has its own stack; we then do the fixup in the #DF handler. (Making #GP an IST exception would make the msr_safe functions unsafe in NMI/MC context, and quite possibly have other effects.) Special thanks to: - Andy Lutomirski, for the suggestion of using very small stack slots and copy (as opposed to map) the IRET frame there, and for the suggestion to mark them readonly and let the fault promote to #DF. - Konrad Wilk for paravirt fixup and testing. - Borislav Petkov for testing help and useful comments. Reported-by: Brian Gerst Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Cc: Konrad Rzeszutek Wilk Cc: Borislav Petkov Cc: Andrew Lutomriski Cc: Linus Torvalds Cc: Dirk Hohndel Cc: Arjan van de Ven Cc: comex Cc: Alexander van Heukelum Cc: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit e7836514086d53e0ffaee18d67d85d9477ecdb12) [wt: backport notes for 2.6.32 differences : - use DECLARE_PER_CPU instead of DECLARE_PER_CPU_READ_MOSTLY - replace this_cpu_read(foo) with per_cpu(foo, smp_processor_id()) - replace this_cpu_write(foo,bar) with per_cpu(foo,smp_processor_id())=bar /wt] Signed-off-by: Willy Tarreau commit b01d7cd1de2a22665ba5d06be43d353709eb7f1f Author: H. Peter Anvin Date: Wed Apr 30 14:03:25 2014 -0700 x86-32, espfix: Remove filter for espfix32 due to race commit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream. It is not safe to use LAR to filter when to go down the espfix path, because the LDT is per-process (rather than per-thread) and another thread might change the descriptors behind our back. Fortunately it is always *safe* (if a bit slow) to go down the espfix path, and a 32-bit LDT stack segment is extremely rare. Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit 6806fa8b6795aba9be8742a8f598f60eed26f875) Signed-off-by: Willy Tarreau commit 1d97cac8c0469759c979e9f2d48ef4122c543e3d Author: H. Peter Anvin Date: Sun Mar 16 15:31:54 2014 -0700 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream. The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 32-bit mode. Since 16-bit support is somewhat crippled anyway on a 64-bit kernel (no V86 mode), and most (if not quite all) 64-bit processors support virtualization for the users who really need it, simply reject attempts at creating a 16-bit segment when running on top of a 64-bit kernel. Cc: Linus Torvalds Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org Signed-off-by: Ben Hutchings (cherry picked from 3.2 commit a862b5c4076b1ba4dd6c87aebac478853dc6db47) Signed-off-by: Willy Tarreau commit ddd12e4e3fdbd0906fe30aef5b51ecebc71d2af6 Author: Jan Beulich Date: Thu Sep 2 13:54:32 2010 +0100 x86-64: Adjust frame type at paranoid_exit: As this isn't an exception or interrupt entry point, it doesn't have any of the hardware provide frame layouts active. Signed-off-by: Jan Beulich Acked-by: Alexander van Heukelum LKML-Reference: <4C7FBAA80200007800013F67@vpn.id2.novell.com> Signed-off-by: Ingo Molnar (cherry picked from commit 1f130a783a796f147b080c594488b566c86007d0) [WT: only merged to minimize changes from mainline in entry_64.S] Signed-off-by: Willy Tarreau commit 0d095eeb523a52bfc7a192eb3c688dee14c55408 Author: Brian Gerst Date: Mon Oct 12 10:18:23 2009 -0400 x86, 64-bit: Move K8 B step iret fixup to fault entry asm Move the handling of truncated %rip from an iret fault to the fault entry path. This allows x86-64 to use the standard search_extable() function. Signed-off-by: Brian Gerst Cc: Linus Torvalds Cc: Jan Beulich LKML-Reference: <1255357103-5418-1-git-send-email-brgerst@gmail.com> Signed-off-by: Ingo Molnar (cherry picked from commit ae24ffe5ecec17c956ac25371d7c2e12b4b36e53) [wt: only merged to fix patch context and ease merging of next patches] Signed-off-by: Willy Tarreau commit 25761523045b78fec26626d85ae44539538bbc6c Author: Willy Tarreau Date: Sat Dec 6 15:14:58 2014 +0100 net: sendmsg: fix failed backport of "fix NULL pointer dereference" Luis Henriques reported that while backporting commit 40eea80 ("net: sendmsg: fix NULL pointer dereference") and applying the diff by hand, I made a typo resulting in the same test being done twice, and msg_name not being tested. This fixes cf90357 ("net: sendmsg: fix NULL pointer dereference") which was merged into 2.6.32.64. Cc: Andrey Ryabinin Cc: Luis Henriques Signed-off-by: Willy Tarreau