user/sven/linux.git, branch v2.6.26.6

Linux 2.6.26.6

2008-10-09T03:24:05Z

S390: CVE-2008-1514: prevent ptrace padding area read/write in 31-bit mode

2008-10-09T03:23:12Z

commit 3d6e48f43340343d97839eadb1ab7b6a3ea98797 upstream When running a 31-bit ptrace, on either an s390 or s390x kernel, reads and writes into a padding area in struct user_regs_struct32 will result in a kernel panic. This is also known as CVE-2008-1514. Test case available here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/user-area-padding.c?cvsroot=systemtap Steps to reproduce: 1) wget the above 2) gcc -o user-area-padding-31bit user-area-padding.c -Wall -ggdb2 -D_GNU_SOURCE -m31 3) ./user-area-padding-31bit Test status ----------- Without patch, both s390 and s390x kernels panic. With patch, the test case, as well as the gdb testsuite, pass without incident, padding area reads returning zero, writes ignored. Nb: original version returned -EINVAL on write attempts, which broke the gdb test and made the test case slightly unhappy, Jan Kratochvil suggested the change to return 0 on write attempts. Signed-off-by: Jarod Wilson Tested-by: Jan Kratochvil Signed-off-by: Martin Schwidefsky Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman

mm owner: fix race between swapoff and exit

2008-10-09T03:23:12Z

[Here's a backport of 2.6.27-rc8's 31a78f23bac0069004e69f98808b6988baccb6b6 to 2.6.26 or 2.6.26.5: I wouldn't trouble -stable for the (root only) swapoff case which uncovered the bug, but the /proc// case is open to all, so I think worth plugging in the next 2.6.26-stable. - Hugh] There's a race between mm->owner assignment and swapoff, more easily seen when task slab poisoning is turned on. The condition occurs when try_to_unuse() runs in parallel with an exiting task. A similar race can occur with callers of get_task_mm(), such as /proc// or ptrace or page migration. CPU0 CPU1 try_to_unuse looks at mm = task0->mm increments mm->mm_users task 0 exits mm->owner needs to be updated, but no new owner is found (mm_users > 1, but no other task has task->mm = task0->mm) mm_update_next_owner() leaves mmput(mm) decrements mm->mm_users task0 freed dereferencing mm->owner fails The fix is to notify the subsystem via mm_owner_changed callback(), if no new owner is found, by specifying the new task as NULL. Jiri Slaby: mm->owner was set to NULL prior to calling cgroup_mm_owner_callbacks(), but must be set after that, so as not to pass NULL as old owner causing oops. Daisuke Nishimura: mm_update_next_owner() may set mm->owner to NULL, but mem_cgroup_from_task() and its callers need to take account of this situation to avoid oops. Hugh Dickins: Lockdep warning and hang below exec_mmap() when testing these patches. exit_mm() up_reads mmap_sem before calling mm_update_next_owner(), so exec_mmap() now needs to do the same. And with that repositioning, there's now no point in mm_need_new_owner() allowing for NULL mm. Reported-by: Hugh Dickins Signed-off-by: Balbir Singh Signed-off-by: Jiri Slaby Signed-off-by: Daisuke Nishimura Signed-off-by: Hugh Dickins Cc: KAMEZAWA Hiroyuki Cc: Paul Menage Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-09T03:23:11Z

commit 2e4a75cdcb89ff53bb182dda3a6dcdc14befe007 upstream When userspace uses SIGIO notification and forgets to disable it before closing file descriptor, rtc->async_queue contains stale pointer to struct file. When user space enables again SIGIO notification in different process, kernel dereferences this (poisoned) pointer and crashes. So disable SIGIO notification on close. Kernel panic: (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq)) general protection fault: 0000 [1] PREEMPT CPU 0 Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363 RIP: 0010:[] [] __lock_acquire+0x3db/0x73f RSP: 0000:ffffffff80674cb8 EFLAGS: 00010002 RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0 RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001 R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000 R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000 FS: 00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080) Stack: ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000 ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002 0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a Call Trace: [] lock_acquire+0x85/0xa9 [] ? send_sigio+0x2a/0x184 [] _read_lock+0x3e/0x4a [] ? send_sigio+0x2a/0x184 [] send_sigio+0x2a/0x184 [] ? __lock_acquire+0x6e1/0x73f [] ? kill_fasync+0x2c/0x4e [] __kill_fasync+0x54/0x65 [] kill_fasync+0x3a/0x4e [] rtc_update_irq+0x9c/0xa5 [] cmos_interrupt+0xae/0xc0 [] handle_IRQ_event+0x25/0x5a [] handle_edge_irq+0xdd/0x123 [] do_IRQ+0xe4/0x144 [] ret_from_intr+0x0/0xf [] ? __alloc_pages_internal+0xe7/0x3ad [] ? clear_page_c+0x7/0x10 [] ? get_page_from_freelist+0x385/0x450 [] ? __alloc_pages_internal+0xe7/0x3ad [] ? anon_vma_prepare+0x2e/0xf6 [] ? handle_mm_fault+0x227/0x6a5 [] ? do_page_fault+0x494/0x83f [] ? error_exit+0x0/0xa9 Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8 RIP [] __lock_acquire+0x3db/0x73f RSP ---[ end trace 431877d860448760 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by: Marcin Slusarz Acked-by: Alessandro Zummo Acked-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fbcon: fix monochrome color value calculation

2008-10-09T03:23:11Z

commit 08650869e0ec581f8d88cfdb563d37f5383abfe2 upstream Commit 22af89aa0c0b4012a7431114a340efd3665a7617 ("fbcon: replace mono_col macro with static inline") changed the order of operations for computing monochrome color values. This generates 0xffff000f instead of 0x0000000f for a 4 bit monochrome color, leading to image corruption if it is passed to cfb_imageblit or other similar functions. Fix it up. Cc: Harvey Harrison Cc: "Antonino A. Daplas" Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ALSA: snd-powermac: HP detection for 1st iMac G3 SL

2008-10-09T03:23:11Z

commit 030b655b062fe5190fc490e0091ea50307d7a86f upstream Correct headphone detection for 1st generation iMac G3 Slot-loading (Screamer). This patch fixes the regression in the recent snd-powermac which doesn't support some G3/G4 PowerMacs: http://lkml.org/lkml/2008/10/1/220 Signed-off-by: Risto Suominen Tested-by: Mariusz Kozlowski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: snd-powermac: mixers for PowerMac G4 AGP

2008-10-09T03:23:11Z

commit 4dbf95ba6c344186ec6d38ff514dc675da464bec upstream Add mixer controls for PowerMac G4 AGP (Screamer). This patch fixes the regression in the recent snd-powermac which doesn't support some G3/G4 PowerMacs: http://lkml.org/lkml/2008/10/1/220 Signed-off-by: Risto Suominen Tested-by: Mariusz Kozlowski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

braille_console: only register notifiers when the braille console is used

2008-10-09T03:23:11Z

commit c0c9209ddd96bc4f1d70a8b9958710671e076080 upstream Only register the braille driver VT and keyboard notifiers when the braille console is used. Avoids eating insert or backspace keys. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=11242 Signed-off-by: Pascal Terjan Signed-off-by: Samuel Thibault Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman

sparc64: Fix missing devices due to PCI bridge test in of_create_pci_dev().

2008-10-09T03:23:10Z

[ Upstream commit 44b50e5a1af13c605d6c3b17a60e42eb0ee48d5f ] Just like in the arch/sparc64/kernel/of_device.c code fix commit 071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix disappearing PCI devices on e3500.") we have to check the OF device node name for "pci" instead of relying upon the 'device_type' property being there on all PCI bridges. Tested by Meelis Roos, and confirmed to make the PCI QFE devices reappear on the E3500 system. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

sparc64: Fix disappearing PCI devices on e3500.

2008-10-09T03:23:10Z

[ Upstream commit 7ee766d8fba9dfd93bf3eca7a8d84a25404a68dc ] Based upon a bug report by Meelis Roos. The OF device layer builds properties by matching bus types and applying 'range' properties as appropriate, up to the root. The match for "PCI" busses is looking at the 'device_type' property, and this does work %99 of the time. But on an E3500 system with a PCI QFE card, the DEC 21153 bridge sitting above the QFE network interface devices has a 'name' of "pci", but it completely lacks a 'device_type' property. So we don't match it as a PCI bus, and subsequently we end up with no resource values at all for the devices sitting under that DEC bridge. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman