Revert "drm/i915: disable PCH ports if needed when disabling a CRTC" This reverts commit bbeaf8811ba070fd186dfcabc957044c3a1149ac. It was found that this change is bringing regressions, as can be seen on Ubuntu bugs 814325, 838181. While a solution isn't found, the change is being reverted. BugLink: http://bugs.launchpad.net/bugs/814325 BugLink: http://bugs.launchpad.net/bugs/838181 Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
ext4: Fix max file size and logical block counting of extent format file, CVE-2011-2695 Kazuya Mio reported that he was able to hit BUG_ON(next == lblock) in ext4_ext_put_gap_in_cache() while creating a sparse file in extent format and fill the tail of file up to its end. We will hit the BUG_ON when we write the last block (2^32-1) into the sparse file. The root cause of the problem lies in the fact that we specifically set s_maxbytes so that block at s_maxbytes fit into on-disk extent format, which is 32 bit long. However, we are not storing start and end block number, but rather start block number and length in blocks. It means that in order to cover extent from 0 to EXT_MAX_BLOCK we need EXT_MAX_BLOCK+1 to fit into len (because we counting block 0 as well) - and it does not. The only way to fix it without changing the meaning of the struct ext4_extent members is, as Kazuya Mio suggested, to lower s_maxbytes by one fs block so we can cover the whole extent we can get by the on-disk extent format. Also in many places EXT_MAX_BLOCK is used as length instead of maximum logical block number as the name suggests, it is all a bit messy. So this commit renames it to EXT_MAX_BLOCKS and change its usage in some places to actually be maximum number of blocks in the extent. The bug which this commit fixes can be reproduced as follows: dd if=/dev/zero of=/mnt/mp1/file bs=<blocksize> count=1 seek=$((2**32-2)) sync dd if=/dev/zero of=/mnt/mp1/file bs=<blocksize> count=1 seek=$((2**32-1)) Reported-by: Kazuya Mio <k-mio@sx.jp.nec.com> Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> (backported from commit f17722f917b2f21497deb6edc62fb1683daa08e6) CVE-2011-2695 BugLink: http://bugs.launchpad.net/bugs/819574 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: Unregister input device only if it is registered BugLink: https://bugs.launchpad.net/bugs/839238 dev2 is not registered in alps_model_quirk_enabled mode, do not unregister while disconnecting. Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
rt2x00: Serialize TX operations on a queue. BugLink: https://bugs.launchpad.net/bugs/855239 The rt2x00 driver gets frequent occurrences of the following error message when operating under load: phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2. This is caused by simultaneous attempts from mac80211 to send a frame via rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame, causing the second frame to fail sending with the above mentioned error message. Fix this by introducing a per-queue spinlock to serialize the TX operations on that queue. Reported-by: Andreas Hartmann <andihartmann@01019freenet.de> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> (backported from upstream commit 77a861c405da75d81e9e6e32c50eb7f9777777e8) Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: [Config] Include all filesystem modules for virtual We got another module inclusion request for the virtual package: quota. Filesystems are not hardware dependant and someone will come and want any missing one sooner or later. So instead of just adding quota, get over with it and just include them all. This is what we finally did for Lucid, too. BugLink: http://bugs.launchpad.net/bugs/761809 Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy BugLink: http://bugs.launchpad.net/bugs/843892 Problem: A repeatable Oops can be caused if a container with networking unshared is destroyed when it has nf_conntrack entries yet to expire. A copy of the oops follows below. A perl program generating the oops repeatably is attached inline below. Analysis: The oops is called from cleanup_net when the namespace is destroyed. conntrack iterates through outstanding events and calls death_by_timeout on each of them, which in turn produces a call to ctnetlink_conntrack_event. This calls nf_netlink_has_listeners, which oopses because net->nfnl is NULL. The perl program generates the container through fork() then clone(NS_NEWNET). I does not explicitly set up netlink explicitly set up netlink, but I presume it was set up else net->nfnl would have been NULL earlier (i.e. when an earlier connection timed out). This would thus suggest that net->nfnl is made NULL during the destruction of the container, which I think is done by nfnetlink_net_exit_batch. I can see that the various subsystems are deinitialised in the opposite order to which the relevant register_pernet_subsys calls are called, and both nf_conntrack and nfnetlink_net_ops register their relevant subsystems. If nfnetlink_net_ops registered later than nfconntrack, then its exit routine would have been called first, which would cause the oops described. I am not sure there is anything to prevent this happening in a container environment. Whilst there's perhaps a more complex problem revolving around ordering of subsystem deinit, it seems to me that missing a netlink event on a container that is dying is not a disaster. An early check for net->nfnl being non-NULL in ctnetlink_conntrack_event appears to fix this. There may remain a potential race condition if it becomes NULL immediately after being checked (I am not sure any lock is held at this point or how synchronisation for subsystem deinitialization works). Patch: The patch attached should apply on everything from 2.6.26 (if not before) onwards; it appears to be a problem on all kernels. This was taken against Ubuntu-3.0.0-11.17 which is very close to 3.0.4. I have torture-tested it with the above perl script for 15 minutes or so; the perl script hung the machine within 20 seconds without this patch. Applicability: If this is the right solution, it should be applied to all stable kernels as well as head. Apart from the minor overhead of checking one variable against NULL, it can never 'do the wrong thing', because if net->nfnl is NULL, an oops will inevitably result. Therefore, checking is a reasonable thing to do unless it can be proven than net->nfnl will never be NULL. Check net->nfnl for NULL in ctnetlink_conntrack_event to avoid Oops on container destroy Signed-off-by: Alex Bligh <alex@alex.org.uk> Cc: Patrick McHardy <kaber@trash.net> Cc: David Miller <davem@davemloft.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (applied from -mm http://marc.info/?l=linux-mm-commits&m=131603308900694&w=2) Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: x86: reboot: Make Dell Latitude E6520 use reboot=pci BugLink: http://bugs.launchpad.net/bugs/833705 The Dell Latitude E6520 doesn't reboot unless reboot=pci is set. Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: x86: reboot: Make Dell Latitude E6220 use reboot=pci BugLink: http://bugs.launchpad.net/bugs/838402 The Dell Latitude E6220 doesn't reboot unless reboot=pci is set. Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message BugLink: http://bugs.launchpad.net/bugs/760131 Fix the printk_once() so that it actually prints (didn't print before due to a stray comma.) [ hpa: changed to an incremental patch and adjusted the description accordingly. ] Signed-off-by: Len Brown <len.brown@intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980 Cc: <table@kernel.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> (cherry picked from commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com>
x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS BugLink: http://bugs.launchpad.net/bugs/760131 Since 2.6.36 (23016bf0d25), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7b40), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS. However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems... Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode... Initialize the MSR to the "normal" by default during kernel boot. x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference. Signed-off-by: Len Brown <len.brown@intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980 Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@kernel.org> (cherry picked from commit abe48b108247e9b90b4c6739662a2e5c765ed114) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
net: Compute protocol sequence numbers and fragment IDs using MD5, CVE-2011-3188 Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by: Dan Kaminsky <dan@doxpara.com> Tested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> (backported from commit 6e5714eaf77d79ae1c8b47e3e040ff5411b717ec) CVE-2011-3188 BugLink: http://bugs.launchpad.net/bugs/834129 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
crypto: Move md5_transform to lib/md5.c, CVE-2011-3188 We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit bc0b96b54a21246e377122d54569eef71cec535f) CVE-2011-3188 BugLink: http://bugs.launchpad.net/bugs/834129 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Bluetooth: Prevent buffer overflow in l2cap config request, CVE-2011-2497 A remote user can provide a small value for the command size field in the command header of an l2cap configuration request, resulting in an integer underflow when subtracting the size of the configuration request header. This results in copying a very large amount of data via memcpy() and destroying the kernel heap. Check for underflow. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Cc: stable <stable@kernel.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> (backported from commit 7ac28817536797fd40e9646452183606f9e17f71) CVE-2011-2497 BugLink: http://bugs.launchpad.net/bugs/838423 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
si4713-i2c: avoid potential buffer overflow on si4713, CVE-2011-2700 BugLink: http://bugs.launchpad.net/bugs/844370 CVE-2011-2700 While compiling it with Fedora 15, I noticed this issue: inlined from ‘si4713_write_econtrol_string’ at drivers/media/radio/si4713-i2c.c:1065:24: arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> Acked-by: Eduardo Valentin <edubezval@gmail.com> Reviewed-by: Eugene Teo <eugeneteo@kernel.sg> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit dc6b845044ccb7e9e6f3b7e71bd179b3cf0223b6) Signed-off-by: Andy Whitcroft <andy.whitcroft@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
inet_diag: fix inet_diag_bc_audit(), CVE-2011-2213 A malicious user or buggy application can inject code and trigger an infinite loop in inet_diag_bc_audit() Also make sure each instruction is aligned on 4 bytes boundary, to avoid unaligned accesses. Reported-by: Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d) CVE-2011-2213 BugLink: http://bugs.launchpad.net/bugs/838421 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
gro: Only reset frag0 when skb can be pulled, CVE-2011-2723 Currently skb_gro_header_slow unconditionally resets frag0 and frag0_len. However, when we can't pull on the skb this leaves the GRO fields in an inconsistent state. This patch fixes this by only resetting those fields after the pskb_may_pull test. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 17dd759c67f21e34f2156abcf415e1f60605a188) CVE-2011-2723 BugLink: http://bugs.launchpad.net/bugs/844371 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
befs: Validate length of long symbolic links, CVE-2011-2928 Signed-off-by: Timo Warns <warns@pre-sense.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 338d0f0a6fbc82407864606f5b64b75aeb3c70f2) CVE-2011-2928 BugLink: http://bugs.launchpad.net/bugs/834124 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
cifs: fix possible memory corruption in CIFSFindNext, CVE-2011-3191 The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. Cc: <stable@kernel.org> Reported-by: Darren Lavender <dcl@hppine99.gbr.hp.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de> (cherry-picked from commit c32dfffaf59f73bbcf4472141b851a4dc5db2bf0 cifs-2.6.git) CVE-2011-3191 BugLink: http://bugs.launchpad.net/bugs/834135 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>