- 10 Nov, 2008 6 commits
-
-
Johannes Berg authored
commit 48735d8d upstream If somebody sends an invalid beacon/probe response, that can trash the whole BSS descriptor. The descriptor is, luckily, large enough so that it cannot scribble past the end of it; it's well above 400 bytes long. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Miller authored
commit f8d570a4 and 3b53fbf4 upstream (because once wasn't good enough...) __scm_destroy() walks the list of file descriptors in the scm_fp_list pointed to by the scm_cookie argument. Those, in turn, can close sockets and invoke __scm_destroy() again. There is nothing which limits how deeply this can occur. The idea for how to fix this is from Linus. Basically, we do all of the fput()s at the top level by collecting all of the scm_fp_list objects hit by an fput(). Inside of the initial __scm_destroy() we keep running the list until it is empty. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Andrew Vasquez authored
commit 031e134e upstream Firmware does not have the facilities to issue management server IOCBs. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Ferenc Wagner <wferi@niif.hu> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 3b274f44 upstream The cell_edac driver is setting the edac_mode field of the csrow's to an incorrect value, causing the sysfs show routine for that field to go out of an array bound and Oopsing the kernel when used. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Eric Sandeen authored
This is a trivial backport of the following upstream commits: - bd39597c (ext2) - cdbf6dba (ext3) - 9d9f1775 (ext4) This addresses CVE-2008-3528 ext[234]: Avoid printk floods in the face of directory corruption Note: some people thinks this represents a security bug, since it might make the system go away while it is printing a large number of console messages, especially if a serial console is involved. Hence, it has been assigned CVE-2008-3528, but it requires that the attacker either has physical access to your machine to insert a USB disk with a corrupted filesystem image (at which point why not just hit the power button), or is otherwise able to convince the system administrator to mount an arbitrary filesystem image (at which point why not just include a setuid shell or world-writable hard disk device file or some such). Me, I think they're just being silly. --tytso Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: linux-ext4@vger.kernel.org Cc: Eugene Teo <eugeneteo@kernel.sg> Signed-off-by:
-
David Brownell authored
commit 978ccaa8 upstream We can get the following oops from gpio_get_value_cansleep() when a GPIO controller doesn't provide a get() callback: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x00000000 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [00000000] 0x0 LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50 Call Trace: [c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94 [c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c [c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0 [c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc [c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c [c7b79f10] [c008f580] sys_read+0x4c/0x90 [c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38 It's OK to request the value of *any* GPIO; most GPIOs are bidirectional, so configuring them as outputs just enables an output driver and doesn't disable the input logic. So the problem is that gpio_get_value_cansleep() isn't making the same sanity check that gpio_get_value() does: making sure this GPIO isn't one of the atypical "no input logic" cases. Reported-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
- 22 Oct, 2008 28 commits
-
-
Greg Kroah-Hartman authored
-
Arjan van de Ven authored
commit 5ba2f67a upstream NULL function pointers are very bad security wise. This one got caught by kerneloops.org quite a few times, so it's happening in the field.... Fix is simple, check the function pointer for NULL, like 6 other places in the same function are already doing. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Michael Krufky authored
(cherry picked from commit a636da6b) DVB: au0828: add support for another USB id for Hauppauge HVR950Q Add autodetection support for a new revision of the Hauppauge HVR950Q (2040:721e) Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Matthias Hopf authored
commit 4b408939 upstream Olaf Kirch noticed that the i915_set_status_page() function of the i915 kernel driver calls ioremap with an address offset that is supplied by userspace via ioctl. The function zeroes the mapped memory via memset and tells the hardware about the address. Turns out that access to that ioctl is not restricted to root so users could probably exploit that to do nasty things. We haven't tried to write actual exploit code though. It only affects the Intel G33 series and newer. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Zhao Yakui authored
upstream commmit: c2c78905 According to acpi spec , the objectes of _BCL and _BCM are required if integrated LCD is present and supports brightness level and the _BQC is the optional object. So the _BQC object will be ignored when the backlight device is registered. At the same time when there is no _BQC object, the current brightness will be set to the maximum. http://bugzilla.kernel.org/show_bug.cgi?id=10206Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
-
Jean Delvare authored
based on commit 98dd22c3 upstream On the Shuttle SN68PT, FAN_CTL2 is apparently not connected to a fan, but to something else. One user has reported instant system power-off when changing the PWM2 duty cycle, so we disable it. I use the board name string as the trigger in case the same board is ever used in other systems. This closes lm-sensors ticket #2349: pwmconfig causes a hard poweroff http://www.lm-sensors.org/ticket/2349Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Linus Torvalds authored
commit b5ff7df3 upstream Check mapped ranges on sysfs resource files This is loosely based on a patch by Jesse Barnes to check the user-space PCI mappings though the sysfs interfaces. Quoting Jesse's original explanation: It's fairly common for applications to map PCI resources through sysfs. However, with the current implementation, it's possible for an application to map far more than the range corresponding to the resourceN file it opened. This patch plugs that hole by checking the range at mmap time, similar to what is done on platforms like sparc64 in their lower level PCI remapping routines. It was initially put together to help debug the e1000e NVRAM corruption problem, since we initially thought an X driver might be walking past the end of one of its mappings and clobbering the NVRAM. It now looks like that's not the case, but doing the check is still important for obvious reasons. and this version of the patch differs in that it uses a helper function to clarify the code, and does all the checks in pages (instead of bytes) in order to avoid overflows when doing "<< PAGE_SHIFT" etc. [cebbert@redhat.com: backport, changing WARN() to printk()] Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
David Rientjes authored
commit 60e6258cd43f9b06884f04f0f7cefb9c40f17a32 upstream It's possible for get_wchan() to dereference past task->stack + THREAD_SIZE while iterating through instruction pointers if fp equals the upper boundary, causing a kernel panic. Signed-off-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Shaohua Li authored
commit 149e1637 upstream Disable ASPM on pre-1.1 PCIe devices, as many of them don't implement it correctly. Tested-by:
Jack Howarth <howarth@bromo.msbb.uc.edu> Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Shaohua Li authored
commit 5fde244d upstream The ACPI FADT table includes an ASPM control bit. If the bit is set, do not enable ASPM since it may indicate that the platform doesn't actually support the feature. Tested-by:
-
Ralph Loader authored
Commit fe6c700f upstream V4L/DVB (9053): fix buffer overflow in uvc-video There is a buffer overflow in drivers/media/video/uvc/uvc_ctrl.c: INFO: 0xf2c5ce08-0xf2c5ce0b. First byte 0xa1 instead of 0xcc INFO: Allocated in uvc_query_v4l2_ctrl+0x3c/0x239 [uvcvideo] age=13 cpu=1 pid=4975 ... A fixed size 8-byte buffer is allocated, and a variable size field is read into it; there is no particular bound on the size of the field (it is dependent on hardware and configuration) and it can overflow [also verified by inserting printk's.] The patch attempts to size the buffer to the correctly. Signed-off-by:
Laurent Pinchart <laurent.pinchart@skynet.be> Signed-off-by:
-
Laurent Pinchart authored
commit 04793dd0 upstream Data buffers on the stack are not allowed for USB I/O. Use dynamically allocated buffers instead. Signed-off-by:
Bruce Schmid <duck@freescale.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Laurent Pinchart authored
commit 54812c77 upstream [required to get the following two patches to apply] Although the V4L2 spec states that the minimum and maximum fields may not be valid for control types other than V4L2_CTRL_TYPE_INTEGER, it makes sense to set the bounds to 0 and 1 for boolean controls instead of returning uninitialized values. Signed-off-by:
-
Linus Torvalds authored
commit efc968d4 upstream This is debatable, but while we're debating it, let's disallow the combination of splice and an O_APPEND destination. It's not entirely clear what the semantics of O_APPEND should be, and POSIX apparently expects pwrite() to ignore O_APPEND, for example. So we could make up any semantics we want, including the old ones. But Miklos convinced me that we should at least give it some thought, and that accepting writes at arbitrary offsets is wrong at least for IS_APPEND() files (which always have O_APPEND set, even if the reverse isn't true: you can obviously have O_APPEND set on a regular file). So disallow O_APPEND entirely for now. I doubt anybody cares, and this way we have one less gray area to worry about. Reported-and-argued-for-by:
Miklos Szeredi <miklos@szeredi.hu> Acked-by:
Jens Axboe <ens.axboe@oracle.com> Signed-off-by:
-
Jean Delvare authored
cherry picked from commit a30ee3c7 The zr36067 driver is improperly declaring pixel format RGBP twice, once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is actually RGBR. Fix the code to properly map both pixel formats. Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Signed-off-by:
-
Jean Delvare authored
(cherry picked from commit c37396c1) Fix the following crash in the bttv driver: BUG: unable to handle kernel NULL pointer dereference at 000000000000036c IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv] This happens because radio_open assumes that all present bttv devices have a radio function. If a bttv device without radio and one with radio are installed on the same system, and the one without radio is registered first, then radio_open checks for the radio device number of a bttv device that has no radio function, and this breaks. All we have to do to fix it is to skip bttv devices without a radio function. Signed-off-by:
-
Taisuke Yamada authored
commit 97b697a1 upstream I recently bought 3 HGST P7K500-series 500GB SATA drives and had trouble accessing the block right on the LBA28-LBA48 border. Here's how it fails (same for all 3 drives): # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null dd: reading `/dev/sdc': Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s # dmesg ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: BMDMA stat 0x25 ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error) ata1.00: status: { DRDY ERR } ata1.00: error: { ABRT } ata1.00: configured for UDMA/33 ata1: EH complete ... After some investigations, it turned out this seems to be caused by misinterpretation of the ATA specification on LBA28 access. Following part is the code in question: === include/linux/ata.h === static inline int lba_28_ok(u64 block, u32 n_block) { /* check the ending block number */ return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256); } HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff, n_block = 1}, and this behavior seems to be comformant. Other drives, including other HGST drives are not that strict, through. >From the ATA specification: (http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf) 8.15.29 Word (61:60): Total number of user addressable sectors This field contains a value that is one greater than the total number of user addressable sectors (see 6.2). The maximum value that shall be placed in this field is 0FFFFFFFh. So the driver shouldn't use the value of 0xfffffff for LBA28 request as this exceeds maximum user addressable sector. The logical maximum value for LBA28 is 0xffffffe. The obvious fix is to cut "- 1" part, and the patch attached just do that. I've been using the patched kernel for about a month now, and the same fix is also floating on the net for some time. So I believe this fix works reliably. Just FYI, many Windows/Intel platform users also seems to be struck by this, and HGST has issued a note pointing to Intel ICH8/9 driver. "28-bit LBA command is being used to access LBAs 29-bits in length" http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23 Also, *BSDs seems to have similar fix included sometime around ~2004, through I have not checked out exact portion of the code. Signed-off-by:
Taisuke Yamada <tai@rakugaki.org> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Tejun Heo authored
Commit a674050e upstream ehc->i.action got accidentally overwritten to ATA_EH_HARD/SOFTRESET in ata_eh_reset(). The original intention was to clear reset action which wasn't selected. This can cause unexpected behavior when other EH actions are scheduled together with reset. Fix it. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Tejun Heo authored
commit 5dbfc9cb upstream As an optimization, follow-up SRST used to be skipped if classification wasn't requested even when hardreset requested it via -EAGAIN. However, some hardresets can't wait for device readiness and skipping SRST can cause timeout or other failures during revalidation. Always perform follow-up SRST if hardreset returns -EAGAIN. This makes reset paths more predictable and thus less error-prone. While at it, move hardreset error checking such that it's done right after hardreset is finished. This simplifies followup SRST condition check a bit and makes the reset path easier to modify. Signed-off-by:
-
Oleg Nesterov authored
commit 232fb69a upstream echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another console. Result: BUG: unable to handle kernel paging request at ffffc20005d00000 IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0 Oops: 0002 [1] SMP CPU 1 Modules linked in: [...a lot...] Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1 RIP: 0010:[bitfill_aligned+149/265] [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109 RSP: 0018:ffff81007d811bc8 EFLAGS: 00010216 RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400 RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000 R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400 FS: 0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000) Stack: ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000 Call Trace: [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba [redraw_screen+261/481] redraw_screen+0x105/0x1e1 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d [complete_change_console+48/190] complete_change_console+0x30/0xbe [change_console+115/120] change_console+0x73/0x78 [console_callback+0/292] ? console_callback+0x0/0x124 [console_callback+97/292] console_callback+0x61/0x124 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e [run_workqueue+139/282] run_workqueue+0x8b/0x11a [worker_thread+221/238] worker_thread+0xdd/0xee [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38 [worker_thread+0/238] ? worker_thread+0x0/0xee [kthread+73/118] kthread+0x49/0x76 [child_rip+10/18] child_rip+0xa/0x12 [kthread+0/118] ? kthread+0x0/0x76 [child_rip+0/18] ? child_rip+0x0/0x12 Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead of fbcon_ops->rotate, and vc_resize() has no effect because it is called with new_cols/rows == ->vc_cols/rows. Tested on 2.6.26.5-45.fc9.x86_64, but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to have the same problem. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Alexey Dobriyan authored
commit e9432093 upstream Fix "notes" kobject leak It happens every rmmod if KALLSYMS=y and SYSFS=y. # modprobe foo kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module' kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '<NULL>' kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo' kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>' ^^^^^ # rmmod foo kobject: 'holders' (ffff88017e7c5770): kobject_cleanup kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del kobject: 'holders' (ffff88017e7c5770): calling ktype release kobject: (ffff88017e7c5770): dynamic_kobj_release kobject: 'holders': free name kobject: 'foo' (ffffffffa00743d0): kobject_cleanup kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed. kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo' kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del kobject: 'foo': free name [whooops] Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Larry Finger authored
commit c6a2afda upstream Date: Sat, 6 Sep 2008 16:51:22 -0500 Subject: b43legacy: Fix failure in rate-adjustment mechanism A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Steve French authored
commit 0752f152 upstream When we do a seekdir() or equivalent, we usually end up doing a FindFirst call and then call FindNext until we get to the offset that we want. The problem is that when we call FindNext, the code usually doesn't have the proper info (mostly, the filename of the entry from the last search) to resume the search. Add a "last_entry" field to the cifs_search_info that points to the last entry in the search. We calculate this pointer by using the LastNameOffset field from the search parms that are returned. We then use that info to do a cifs_save_resume_key before we call CIFSFindNext. This patch allows CIFS to reliably pass the "telldir" connectathon test. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Dario Faggioli authored
commit f6121f4f upstream While working on the new version of the code for SCHED_SPORADIC I noticed something strange in the present throttling mechanism. More specifically in the throttling timer handler in sched_rt.c (do_sched_rt_period_timer()) and in rt_rq_enqueue(). The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only asks for rescheduling if the runqueue has a sched_entity associated to it (i.e., rt_rq->rt_se != NULL). Now, if the runqueue is the root rq (which has a rt_se = NULL) rescheduling does not take place, and it is delayed to some undefined instant in the future. This imply some random bandwidth usage by the RT tasks under throttling. For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT task will get less than 95%. In our tests we got something varying between 70% to 95%. Using smaller time values, e.g., 95ms/100ms, things are even worse, and I can see values also going down to 20-25%!! The tests we performed are simply running 'yes' as a SCHED_FIFO task, and checking the CPU usage with top, but we can investigate thoroughly if you think it is needed. Things go much better, for us, with the attached patch... Don't know if it is the best approach, but it solved the issue for us. Signed-off-by:
Dario Faggioli <raistlin@linux.it> Signed-off-by:
Michael Trimarchi <trimarchimichael@yahoo.it> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Alan Cox authored
commit 8f520021 upstream (only the tty_io.c portion of this commit) This moves us towards sanity and should mean our termios locking is now complete and comprehensive. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Alan Cox authored
commit c613ec1a upstream The x86 implementation of early_ioremap has an off by one error. If we get an object which ends on the first byte of a page we undermap by one page and this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit this alignment. The size computation is currently last_addr = phys_addr + size - 1; npages = (PAGE_ALIGN(last_addr) - phys_addr) (Consider a request for 1 byte at alignment 0...) Closes #11693 Debugging work by Ian Campbell/Felix Geyer Signed-off-by:
Alan Cox <alan@rehat.com> Signed-off-by:
-
Thomas Gleixner authored
commit 649c6653 upstream num_possible_cpus() can be > 1 when disabled CPUs have been accounted. Disabled CPUs are not in the cpu_present_map, so we can use num_present_cpus() as a safe indicator to switch to UP alternatives. Reported-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Stefan Bader authored
Not in upstream above 2.6.27 due to change in the way this code works (has been fixed differently there.) Someone from the community found out, that after repeatedly unloading and loading a device driver that uses MSI IRQs, the system eventually assigned the vector initially reserved for IRQ0 to the device driver. The reason for this is, that although IRQ0 is tied to the FIRST_DEVICE_VECTOR when declaring the irq_vector table, the corresponding bit in the used_vectors map is not set. So, if vectors are released and assigned often enough, the vector will get assigned to another interrupt. This happens more often with MSI interrupts as those are exclusively using a vector. Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
- 09 Oct, 2008 6 commits
-
-
Greg Kroah-Hartman authored
-
Jarod Wilson authored
commit 3d6e48f4 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 <panic> 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 <jarod@redhat.com> Tested-by:
Jan Kratochvil <jan.kratochvil@redhat.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Moritz Muehlenhoff <jmm@debian.org> Signed-off-by:
-
Balbir Singh authored
[Here's a backport of 2.6.27-rc8's 31a78f23 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/<pid>/<mmstats> 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/<pid>/<mmstats> 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 <hugh@veritas.com> Signed-off-by:
Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Signed-off-by:
-
Marcin Slusarz authored
commit 2e4a75cd 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:[<ffffffff8024f891>] [<ffffffff8024f891>] __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: <IRQ> [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9 [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff80491d1f>] _read_lock+0x3e/0x4a [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184 [<ffffffff8029cb62>] send_sigio+0x2a/0x184 [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e [<ffffffff8029cd10>] __kill_fasync+0x54/0x65 [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5 [<ffffffff80404640>] cmos_interrupt+0xae/0xc0 [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123 [<ffffffff8020da34>] do_IRQ+0xe4/0x144 [<ffffffff8020bad6>] ret_from_intr+0x0/0xf <EOI> [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10 [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450 [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6 [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5 [<ffffffff80494716>] ? do_page_fault+0x494/0x83f [<ffffffff8049251d>] ? 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 [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f RSP <ffffffff80674cb8> ---[ end trace 431877d860448760 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Acked-by:
Alessandro Zummo <alessandro.zummo@towertech.it> Acked-by:
-
David Winn authored
commit 08650869 upstream Commit 22af89aa ("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 <harvey.harrison@gmail.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by:
-
Risto Suominen authored
commit 030b655b 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/220Signed-off-by:
Risto Suominen <Risto.Suominen@gmail.com> Tested-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
