linux, branch v3.0.8

Linux 3.0.8

2011-10-25T05:11:12Z

hfsplus: Fix kfree of wrong pointers in hfsplus_fill_super() error path

2011-10-25T05:10:17Z

commit f588c960fcaa6fa8bf82930bb819c9aca4eb9347 upstream. Commit 6596528e391a ("hfsplus: ensure bio requests are not smaller than the hardware sectors") changed the pointers used for volume header allocations but failed to free the correct pointers in the error path path of hfsplus_fill_super() and hfsplus_read_wrapper. The second hunk came from a separate patch by Pavel Ivanov. Reported-by: Pavel Ivanov Signed-off-by: Seth Forshee Signed-off-by: Christoph Hellwig Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add position_fix quirk for Dell Inspiron 1010

2011-10-25T05:10:17Z

commit 051a8cb6550d917225ead1cd008b5966350f6d53 upstream. The previous fix for the position-buffer check gives yet another regression on a Dell laptop. The safest fix right now is to add a static quirk for this device (and better to apply it for stable kernels too). Reported-by: Éric Piel Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: HDA: conexant support for Lenovo T520/W520

2011-10-25T05:10:17Z

commit ca201c096269ee2d40037fea96a59fd0695888c4 upstream. This is patch for Conexant codec of Intel HDA driver, adding new quirk for Lenovo Thinkpad T520 and W520. Conexant autodetection works fine for T520 (similar subsystem ID is used also in W520 model) and detects more mixer features compared to generic (fallback) Lenovo quirk with hardcoded options in Conexant codec. Patch was activelly tested with Linux 3.0.4, 3.0.6 and 3.0.7 without any problems. Signed-off-by: Daniel Suchy Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

crypto: ghash - Avoid null pointer dereference if no key is set

2011-10-25T05:10:17Z

commit 7ed47b7d142ec99ad6880bbbec51e9f12b3af74c upstream. The ghash_update function passes a pointer to gf128mul_4k_lle which will be NULL if ghash_setkey is not called or if the most recent call to ghash_setkey failed to allocate memory. This causes an oops. Fix this up by returning an error code in the null case. This is trivially triggered from unprivileged userspace through the AF_ALG interface by simply writing to the socket without setting a key. The ghash_final function has a similar issue, but triggering it requires a memory allocation failure in ghash_setkey _after_ at least one successful call to ghash_update. BUG: unable to handle kernel NULL pointer dereference at 00000670 IP: [] gf128mul_4k_lle+0x23/0x60 [gf128mul] *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ghash_generic gf128mul algif_hash af_alg nfs lockd nfs_acl sunrpc bridge ipv6 stp llc Pid: 1502, comm: hashatron Tainted: G W 3.1.0-rc9-00085-ge9308cf #32 Bochs Bochs EIP: 0060:[] EFLAGS: 00000202 CPU: 0 EIP is at gf128mul_4k_lle+0x23/0x60 [gf128mul] EAX: d69db1f0 EBX: d6b8ddac ECX: 00000004 EDX: 00000000 ESI: 00000670 EDI: d6b8ddac EBP: d6b8ddc8 ESP: d6b8dda4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hashatron (pid: 1502, ti=d6b8c000 task=d6810000 task.ti=d6b8c000) Stack: 00000000 d69db1f0 00000163 00000000 d6b8ddc8 c101a520 d69db1f0 d52aa000 00000ff0 d6b8dde8 d88d310f d6b8a3f8 d52aa000 00001000 d88d502c d6b8ddfc 00001000 d6b8ddf4 c11676ed d69db1e8 d6b8de24 c11679ad d52aa000 00000000 Call Trace: [] ? kmap_atomic_prot+0x37/0xa6 [] ghash_update+0x85/0xbe [ghash_generic] [] crypto_shash_update+0x18/0x1b [] shash_ahash_update+0x22/0x36 [] shash_async_update+0xb/0xd [] hash_sendpage+0xba/0xf2 [algif_hash] [] kernel_sendpage+0x39/0x4e [] ? 0xd88cdfff [] sock_sendpage+0x37/0x3e [] ? kernel_sendpage+0x4e/0x4e [] pipe_to_sendpage+0x56/0x61 [] splice_from_pipe_feed+0x58/0xcd [] ? splice_from_pipe_begin+0x10/0x10 [] __splice_from_pipe+0x36/0x55 [] ? splice_from_pipe_begin+0x10/0x10 [] splice_from_pipe+0x51/0x64 [] ? default_file_splice_write+0x2c/0x2c [] generic_splice_sendpage+0x13/0x15 [] ? splice_from_pipe_begin+0x10/0x10 [] do_splice_from+0x5d/0x67 [] sys_splice+0x2bf/0x363 [] ? sysenter_exit+0xf/0x16 [] ? trace_hardirqs_on_caller+0x10e/0x13f [] sysenter_do_call+0x12/0x32 Code: 83 c4 0c 5b 5e 5f c9 c3 55 b9 04 00 00 00 89 e5 57 8d 7d e4 56 53 8d 5d e4 83 ec 18 89 45 e0 89 55 dc 0f b6 70 0f c1 e6 04 01 d6 a5 be 0f 00 00 00 4e 89 d8 e8 48 ff ff ff 8b 45 e0 89 da 0f EIP: [] gf128mul_4k_lle+0x23/0x60 [gf128mul] SS:ESP 0068:d6b8dda4 CR2: 0000000000000670 ---[ end trace 4eaa2a86a8e2da24 ]--- note: hashatron[1502] exited with preempt_count 1 BUG: scheduling while atomic: hashatron/1502/0x10000002 INFO: lockdep is turned off. [...] Signed-off-by: Nick Bowler Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

x25: Prevent skb overreads when checking call user data

2011-10-25T05:10:17Z

commit 7f81e25befdfb3272345a2e775f520e1d515fa20 upstream. x25_find_listener does not check that the amount of call user data given in the skb is big enough in per-socket comparisons, hence buffer overreads may occur. Fix this by adding a check. Signed-off-by: Matthew Daley Cc: Eric Dumazet Cc: Andrew Hendry Acked-by: Andrew Hendry Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mm: fix race between mremap and removing migration entry

2011-10-25T05:10:17Z

commit 486cf46f3f9be5f2a966016c1a8fe01e32cde09e upstream. I don't usually pay much attention to the stale "? " addresses in stack backtraces, but this lucky report from Pawel Sikora hints that mremap's move_ptes() has inadequate locking against page migration. 3.0 BUG_ON(!PageLocked(p)) in migration_entry_to_page(): kernel BUG at include/linux/swapops.h:105! RIP: 0010:[] [] migration_entry_wait+0x156/0x160 [] handle_pte_fault+0xae1/0xaf0 [] ? __pte_alloc+0x42/0x120 [] ? do_huge_pmd_anonymous_page+0xab/0x310 [] handle_mm_fault+0x181/0x310 [] ? vma_adjust+0x537/0x570 [] do_page_fault+0x11d/0x4e0 [] ? do_mremap+0x2d5/0x570 [] page_fault+0x1f/0x30 mremap's down_write of mmap_sem, together with i_mmap_mutex or lock, and pagetable locks, were good enough before page migration (with its requirement that every migration entry be found) came in, and enough while migration always held mmap_sem; but not enough nowadays, when there's memory hotremove and compaction. The danger is that move_ptes() lets a migration entry dodge around behind remove_migration_pte()'s back, so it's in the old location when looking at the new, then in the new location when looking at the old. Either mremap's move_ptes() must additionally take anon_vma lock(), or migration's remove_migration_pte() must stop peeking for is_swap_entry() before it takes pagetable lock. Consensus chooses the latter: we prefer to add overhead to migration than to mremapping, which gets used by JVMs and by exec stack setup. Reported-and-tested-by: Paweł Sikora Signed-off-by: Hugh Dickins Acked-by: Andrea Arcangeli Acked-by: Mel Gorman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

hwmon: (w83627ehf) Fix negative 8-bit temperature values

2011-10-25T05:10:17Z

commit 133d324d82e144588939ad25b732b5b6c33b03d9 upstream. Since 8-bit temperature values are now handled in 16-bit struct members, values have to be cast to s8 for negative temperatures to be properly handled. This is broken since kernel version 2.6.39 (commit bce26c58df86599c9570cee83eac58bdaae760e4.) Signed-off-by: Jean Delvare Cc: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

x86: Fix S4 regression

2011-10-25T05:10:16Z

commit 8548c84da2f47e71bbbe300f55edb768492575f7 upstream. Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4 regression since 2.6.39, namely the machine reboots occasionally at S4 resume. It doesn't happen always, overall rate is about 1/20. But, like other bugs, once when this happens, it continues to happen. This patch fixes the problem by essentially reverting the memory assignment in the older way. Signed-off-by: Takashi Iwai Cc: Rafael J. Wysocki Cc: Yinghai Lu [ We'll hopefully find the real fix, but that's too late for 3.1 now ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: fix panic after rmmod with slow targets

2011-10-25T05:10:16Z

commit 0278ccd9d53e07c4e699432b2fed9de6c56f506c upstream. If firewire-sbp2 starts a login to a target that doesn't complete ORBs in a timely manner (and has to retry the login), and the module is removed before the operation times out, you end up with a null-pointer dereference and a kernel panic. [SR: This happens because sbp2_target_get/put() do not maintain module references. scsi_device_get/put() do, but at occasions like Chris describes one, nobody holds a reference to an SBP-2 sdev.] This patch cancels pending work for each unit in sbp2_remove(), which hopefully means there are no extra references around that prevent us from unloading. This fixes my crash. Signed-off-by: Chris Boot Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman