opensuse:kernel.git
11 years agoLinux 2.6.16.21
Chris Wright [Tue, 20 Jun 2006 08:55:00 +0000 (01:55 -0700)]
Linux 2.6.16.21

11 years ago[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)
Patrick McHardy [Mon, 19 Jun 2006 17:14:21 +0000 (19:14 +0200)]
[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)

Fix endless loop in the SCTP match similar to those already fixed in the
SCTP conntrack helper (was CVE-2006-1527).

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] run_posix_cpu_timers: remove a bogus BUG_ON() (CVE-2006-2445)
Oleg Nesterov [Thu, 15 Jun 2006 16:11:43 +0000 (20:11 +0400)]
[PATCH] run_posix_cpu_timers: remove a bogus BUG_ON() (CVE-2006-2445)

do_exit() clears ->it_##clock##_expires, but nothing prevents
another cpu to attach the timer to exiting process after that.
arm_timer() tries to protect against this race, but the check
is racy.

After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and
before do_exit() calls 'schedule() local timer interrupt can find
tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu
does sys_wait4) interrupted task has ->signal == NULL.

At this moment exiting task has no pending cpu timers, they were
cleanuped in __exit_signal()->posix_cpu_timers_exit{,_group}(),
so we can just return from irq.

John Stultz recently confirmed this bug, see

http://marc.theaimsgroup.com/?l=linux-kernel&m=115015841413687

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] check_process_timers: fix possible lockup
Oleg Nesterov [Thu, 15 Jun 2006 16:11:15 +0000 (20:11 +0400)]
[PATCH] check_process_timers: fix possible lockup

If the local timer interrupt happens just after do_exit() sets PF_EXITING
(and before it clears ->it_xxx_expires) run_posix_cpu_timers() will call
check_process_timers() with tasklist_lock + ->siglock held and

check_process_timers:

t = tsk;
do {
....

do {
t = next_thread(t);
} while (unlikely(t->flags & PF_EXITING));
} while (t != tsk);

the outer loop will never stop.

Actually, the window is bigger.  Another process can attach the timer
after ->it_xxx_expires was cleared (see the next commit) and the 'if
(PF_EXITING)' check in arm_timer() is racy (see the one after that).

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] powerpc: Fix machine check problem on 32-bit kernels (CVE-2006-2448)
Paul Mackerras [Fri, 9 Jun 2006 03:02:59 +0000 (13:02 +1000)]
[PATCH] powerpc: Fix machine check problem on 32-bit kernels (CVE-2006-2448)

This fixes a bug found by Dave Jones that means that it is possible
for userspace to provoke a machine check on 32-bit kernels.  This
also fixes a couple of other places where I found similar problems
by inspection.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.20
Chris Wright [Mon, 5 Jun 2006 17:18:23 +0000 (10:18 -0700)]
Linux 2.6.16.20

11 years ago[PATCH] sbp2: fix check of return value of hpsb_allocate_and_register_addrspace
Stefan Richter [Sat, 3 Jun 2006 00:00:33 +0000 (02:00 +0200)]
[PATCH] sbp2: fix check of return value of hpsb_allocate_and_register_addrspace

I added a failure check in patch "sbp2: variable status FIFO address
(fix login timeout)" --- alas for a wrong error value.  This is a bug
since Linux 2.6.16.  Leads to NULL pointer dereference if the call
failed, and bogus failure handling if call succeeded.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] sbp2: backport read_capacity workaround for iPod
Stefan Richter [Fri, 2 Jun 2006 17:34:30 +0000 (19:34 +0200)]
[PATCH] sbp2: backport read_capacity workaround for iPod

There is a firmware bug in several Apple iPods which prevents access to
these iPods under certain conditions. The disk size reported by the iPod
is one sector too big. Once access to the end of the disk is attempted,
the iPod becomes inaccessible. This problem has been known for USB iPods
for some time and has recently been discovered to exist with
FireWire/USB combo iPods too.

This patch is derived from the fix in Linux 2.6.17, commit
e9a1c52c7b19d10342226c12f170d7ab644427e2, to be applicable to 2.6.16.x
without prerequisite patches. It hard-wires a workaround for three known
affected model numbers (those of 4th generation iPod, iPod Photo, iPod
mini).

Note: This patch lacks Linux 2.6.17's ability to enable and disable the
workaround via a module parameter.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86_64: Don't do syscall exit tracing twice
Andi Kleen [Thu, 1 Jun 2006 01:26:58 +0000 (03:26 +0200)]
[PATCH] x86_64: Don't do syscall exit tracing twice

This fixes a regression from the earlier DOS fix for non canonical
IRET addresses. It broke UML.

int_ret_from_syscall already does syscall exit tracing, so
no need to do it again in the caller.

This caused problems for UML and some other special programs doing
syscall interception.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86_64: x86_64 add crashdump trigger points
Vivek Goyal [Tue, 18 Apr 2006 10:35:13 +0000 (12:35 +0200)]
[PATCH] x86_64: x86_64 add crashdump trigger points

o Start booting into the capture kernel after an Oops if system is in a
  unrecoverable state. System will boot into the capture kernel, if one is
  pre-loaded by the user, and capture the kernel core dump.

o One of the following conditions should be true to trigger the booting of
  capture kernel.
        - panic_on_oops is set.
        - pid of current thread is 0
        - pid of current thread is 1
        - Oops happened inside interrupt context.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] ipw2200: Filter unsupported channels out in ad-hoc mode
Zhu Yi [Wed, 1 Mar 2006 21:55:51 +0000 (05:55 +0800)]
[PATCH] ipw2200: Filter unsupported channels out in ad-hoc mode

Currently iwlist ethX freq[uency]/channel lists all the channels the card
supported for the current region, which includes some channels can only
be used in infrastructure mode. This patch filters these channels out if
the card is currently in ad-hoc mode.

Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] the latest consensus libata resume fix
Mark Lord [Sun, 28 May 2006 15:28:00 +0000 (11:28 -0400)]
[PATCH] the latest consensus libata resume fix

Okay, just to sum things up.

This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
on resume before continuing.

[jgarzik adds...]  During testing we never saw DRQ asserted, but
nonetheless (a) this works and (b) testing for DRQ won't hurt.

Signed-off-by: Mark Lord <liml@rtr.ca>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] ohci1394, sbp2: fix "scsi_add_device failed" with PL-3507 based devices
Stefan Richter [Sat, 27 May 2006 12:11:18 +0000 (14:11 +0200)]
[PATCH] ohci1394, sbp2: fix "scsi_add_device failed" with PL-3507 based devices

Re-enable posted writes for status FIFO.
Besides bringing back a very minor bandwidth tweak from Linux 2.6.15.x
and older, this also fixes an interoperability regression since 2.6.16:
http://bugzilla.kernel.org/show_bug.cgi?id=6356
(sbp2: scsi_add_device failed. IEEE1394 HD is not working anymore.)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Vanei Heidemann <linux@javanei.com.br>
Tested-by: Martin Putzlocher <mputzi@gmx.de> (chip type unconfirmed)
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Input: psmouse - fix new device detection logic
Dmitry Torokhov [Sat, 29 Apr 2006 09:12:44 +0000 (05:12 -0400)]
[PATCH] Input: psmouse - fix new device detection logic

Input: psmouse - fix new device detection logic

Reported to fix http://bugs.gentoo.org/130846

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] PowerMac: force only suspend-to-disk to be valid
Johannes Berg [Fri, 26 May 2006 01:44:24 +0000 (18:44 -0700)]
[PATCH] PowerMac: force only suspend-to-disk to be valid

For a very long time, echoing 'standby' or 'mem' into /sys/power/state has
killed the machine on powerpc.  This patch fixes that.

This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered.  Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
handle it there regardless just in case that changes.

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Cpuset: might sleep checking zones allowed fix
Paul Jackson [Tue, 23 May 2006 00:56:07 +0000 (17:56 -0700)]
[PATCH] Cpuset: might sleep checking zones allowed fix

Fix an infrequently encountered 'sleeping function called
from invalid context' in the cpuset hooks in __alloc_pages.
Could sleep while interrupts disabled.

The routine cpuset_zone_allowed() is called by code in
mm/page_alloc.c __alloc_pages() to determine if a zone is
allowed in the current tasks cpuset.  This routine can sleep,
for certain GFP_KERNEL allocations, if the zone is on a memory
node not allowed in the current cpuset, but might be allowed
in a parent cpuset.

But we can't sleep in __alloc_pages() if in interrupt, nor
if called for a GFP_ATOMIC request (__GFP_WAIT not set in
gfp_flags).

The rule was intended to be:
  Don't call cpuset_zone_allowed() if you can't sleep, unless you
  pass in the __GFP_HARDWALL flag set in gfp_flag, which disables
  the code that might scan up ancestor cpusets and sleep.

This rule was being violated due to a bogus change made (by myself,
pj) to __alloc_pages() as part of the November 2005 effort to
cleanup its logic.

The bogus change can be seen at:
  http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-11/4691.html
  [PATCH 01/05] mm fix __alloc_pages cpuset ALLOC_* flags

This was first noticed on a tight memory system, in code that
was disabling interrupts and doing allocation requests with
__GFP_WAIT not set, which resulted in __might_sleep() writing
complaints to the log "Debug: sleeping function called ...",
when the code in cpuset_zone_allowed() tried to take the
callback_sem cpuset semaphore.

Special thanks to Dave Chinner, for figuring this out,
and a tip of the hat to Nick Piggin who warned me of this
back in Nov 2005, before I was ready to listen.

Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Altix: correct ioc3 port order
Pat Gefre [Mon, 1 May 2006 19:16:08 +0000 (12:16 -0700)]
[PATCH] Altix: correct ioc3 port order

Currently loading the ioc3 as a module will cause the ports to be numbered
in reverse order.  This mod maintains the proper order of cards for port
numbering.

Signed-off-by: Patrick Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] Altix: correct ioc4 port order
Brent Casavant [Thu, 4 May 2006 02:55:10 +0000 (19:55 -0700)]
[PATCH] Altix: correct ioc4 port order

Currently loading the ioc4 as a module will cause the ports to be numbered
in reverse order.  This mod maintains the proper order of cards for port
numbering.

Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Cc: Pat Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.19
Chris Wright [Wed, 31 May 2006 00:31:44 +0000 (17:31 -0700)]
Linux 2.6.16.19

11 years ago[PATCH] NETFILTER: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)
Marcel Holtmann [Fri, 26 May 2006 11:50:46 +0000 (13:50 +0200)]
[PATCH] NETFILTER: Fix small information leak in SO_ORIGINAL_DST (CVE-2006-1343)

It appears that sockaddr_in.sin_zero is not zeroed during
getsockopt(...SO_ORIGINAL_DST...) operation. This can lead
to an information leak (CVE-2006-1343).

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.18
Chris Wright [Mon, 22 May 2006 18:04:35 +0000 (11:04 -0700)]
Linux 2.6.16.18

11 years ago[PATCH] NETFILTER: SNMP NAT: fix memory corruption (CVE-2006-2444)
Patrick McHardy [Sat, 20 May 2006 07:31:26 +0000 (09:31 +0200)]
[PATCH] NETFILTER: SNMP NAT: fix memory corruption (CVE-2006-2444)

CVE-2006-2444 - Potential remote DoS in SNMP NAT helper.

Fix memory corruption caused by snmp_trap_decode:

- When snmp_trap_decode fails before the id and address are allocated,
  the pointers contain random memory, but are freed by the caller
  (snmp_parse_mangle).

- When snmp_trap_decode fails after allocating just the ID, it tries
  to free both address and ID, but the address pointer still contains
  random memory. The caller frees both ID and random memory again.

- When snmp_trap_decode fails after allocating both, it frees both,
  and the callers frees both again.

The corruption can be triggered remotely when the ip_nat_snmp_basic
module is loaded and traffic on port 161 or 162 is NATed.

Found by multiple testcases of the trap-app and trap-enc groups of the
PROTOS c06-snmpv1 testsuite.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.17
Chris Wright [Sat, 20 May 2006 22:00:46 +0000 (15:00 -0700)]
Linux 2.6.16.17

11 years ago[PATCH] SCTP: Validate the parameter length in HB-ACK chunk (CVE-2006-1857)
Vladislav Yasevich [Fri, 19 May 2006 21:25:53 +0000 (14:25 -0700)]
[PATCH] SCTP: Validate the parameter length in HB-ACK chunk (CVE-2006-1857)

If SCTP receives a badly formatted HB-ACK chunk, it is possible
that we may access invalid memory and potentially have a buffer
overflow.  We should really make sure that the chunk format is
what we expect, before attempting to touch the data.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] SCTP: Respect the real chunk length when walking parameters (CVE-2006-1858)
Vladislav Yasevich [Fri, 19 May 2006 18:52:20 +0000 (11:52 -0700)]
[PATCH] SCTP: Respect the real chunk length when walking parameters (CVE-2006-1858)

When performing bound checks during the parameter processing, we
want to use the real chunk and paramter lengths for bounds instead
of the rounded ones.  This prevents us from potentially walking of
the end if the chunk length was miscalculated.  We still use rounded
lengths when advancing the pointer. This was found during a
conformance test that changed the chunk length without modifying
parameters.

(Vlad noted elsewhere: the most you'd overflow is 3 bytes, so problem
is parameter dependent).

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] ptrace_attach: fix possible deadlock schenario with irqs
Linus Torvalds [Thu, 11 May 2006 18:08:49 +0000 (11:08 -0700)]
[PATCH] ptrace_attach: fix possible deadlock schenario with irqs

Eric Biederman points out that we can't take the task_lock while holding
tasklist_lock for writing, because another CPU that holds the task lock
might take an interrupt that then tries to take tasklist_lock for writing.

Which would be a nasty deadlock, with one CPU spinning forever in an
interrupt handler (although admittedly you need to really work at
triggering it ;)

Since the ptrace_attach() code is special and very unusual, just make it
be extra careful, and use trylock+repeat to avoid the possible deadlock.

Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Fix ptrace_attach()/ptrace_traceme()/de_thread() race
Linus Torvalds [Sun, 7 May 2006 17:49:33 +0000 (10:49 -0700)]
[PATCH] Fix ptrace_attach()/ptrace_traceme()/de_thread() race

This holds the task lock (and, for ptrace_attach, the tasklist_lock)
over the actual attach event, which closes a race between attacking to a
thread that is either doing a PTRACE_TRACEME or getting de-threaded.

Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
for noticing a lost return value in my first version.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] page migration: Fix fallback behavior for dirty pages
Christoph Lameter [Mon, 1 May 2006 19:16:08 +0000 (12:16 -0700)]
[PATCH] page migration: Fix fallback behavior for dirty pages

Currently we check PageDirty() in order to make the decision to swap out
the page.  However, the dirty information may be only be contained in the
ptes pointing to the page.  We need to first unmap the ptes before checking
for PageDirty().  If unmap is successful then the page count of the page
will also be decreased so that pageout() works properly.

This is a fix necessary for 2.6.17.  Without this fix we may migrate dirty
pages for filesystems without migration functions.  Filesystems may keep
pointers to dirty pages.  Migration of dirty pages can result in the
filesystem keeping pointers to freed pages.

Unmapping is currently not be separated out from removing all the
references to a page and moving the mapping.  Therefore try_to_unmap will
be called again in migrate_page() if the writeout is successful.  However,
it wont do anything since the ptes are already removed.

The coming updates to the page migration code will restructure the code
so that this is no longer necessary.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] add migratepage address space op to shmem
Lee Schermerhorn [Sat, 22 Apr 2006 09:35:48 +0000 (02:35 -0700)]
[PATCH] add migratepage address space op to shmem

Basic problem: pages of a shared memory segment can only be migrated once.

In 2.6.16 through 2.6.17-rc1, shared memory mappings do not have a
migratepage address space op.  Therefore, migrate_pages() falls back to
default processing.  In this path, it will try to pageout() dirty pages.
Once a shared memory page has been migrated it becomes dirty, so
migrate_pages() will try to page it out.  However, because the page count
is 3 [cache + current + pte], pageout() will return PAGE_KEEP because
is_page_cache_freeable() returns false.  This will abort all subsequent
migrations.

This patch adds a migratepage address space op to shared memory segments to
avoid taking the default path.  We use the "migrate_page()" function
because it knows how to migrate dirty pages.  This allows shared memory
segment pages to migrate, subject to other conditions such as # pte's
referencing the page [page_mapcount(page)], when requested.

I think this is safe.  If we're migrating a shared memory page, then we
found the page via a page table, so it must be in memory.

Can be verified with memtoy and the shmem-mbind-test script, both
available at:  http://free.linux.hp.com/~lts/Tools/

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] Remove cond_resched in gather_stats()
Christoph Lameter [Thu, 20 Apr 2006 09:43:12 +0000 (02:43 -0700)]
[PATCH] Remove cond_resched in gather_stats()

gather_stats() is called with a spinlock held from check_pte_range.  We
cannot reschedule with a lock held.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] VIA quirk fixup, additional PCI IDs
Chris Wedgwood [Mon, 15 May 2006 16:43:55 +0000 (09:43 -0700)]
[PATCH] VIA quirk fixup, additional PCI IDs

An earlier commit (75cf7456dd87335f574dcd53c4ae616a2ad71a11) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list.  Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.

This should I hope correct this.

Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.

Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges
Chris Wedgwood [Wed, 19 Apr 2006 06:57:09 +0000 (23:57 -0700)]
[PATCH] PCI quirk: VIA IRQ fixup should only run for VIA southbridges

Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
on my system which has no VIA southbridge (but I do have a VIA IEEE
1394 device).

This should address that.  I also changed "Via IRQ" to "VIA IRQ"
(initially I read Via as a capitalized via (by way/means of).

Signed-off-by: Chris Wedgwood <cw@f00f.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] Fix udev device creation
Harald Welte [Wed, 10 May 2006 11:28:52 +0000 (13:28 +0200)]
[PATCH] Fix udev device creation

This patch corrects the order of the calls to register_chrdev() and
pcmcia_register_driver().  Now udev correctly creates userspace device
files /dev/cmmN and /dev/cmxN respectively.

Based on an earlier patch by Jan Niehusmann <jan@gondor.com>.

Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] limit request_fn recursion
Jens Axboe [Thu, 11 May 2006 06:20:16 +0000 (08:20 +0200)]
[PATCH] limit request_fn recursion

Don't recurse back into the driver even if the unplug threshold is met,
when the driver asks for a requeue. This is both silly from a logical
point of view (requeues typically happen due to driver/hardware
shortage), and also dangerous since we could hit an endless request_fn
-> requeue -> unplug -> request_fn loop and crash on stack overrun.

Also limit blk_run_queue() to one level of recursion, similar to how
blk_start_queue() works.

This patch fixed a real problem with SLES10 and lpfc, and it could hit
any SCSI lld that returns non-zero from it's ->queuecommand() handler.

Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] PCI: correctly allocate return buffers for osc calls
Kristen Accardi [Wed, 17 May 2006 18:13:37 +0000 (11:13 -0700)]
[PATCH] PCI: correctly allocate return buffers for osc calls

The OSC set and query functions do not allocate enough space for return values,
and set the output buffer length to a false, too large value.  This causes the
acpi-ca code to assume that the output buffer is larger than it actually is,
and overwrite memory when copying acpi return buffers into this caller provided
buffer.  In some cases this can cause kernel oops if the memory that is
overwritten is a pointer.  This patch will change these calls to use a
dynamically allocated output buffer, thus allowing the acpi-ca code to decide
how much space is needed.

Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] selinux: check for failed kmalloc in security_sid_to_context()
Serge E. Hallyn [Mon, 15 May 2006 16:43:48 +0000 (09:43 -0700)]
[PATCH] selinux: check for failed kmalloc in security_sid_to_context()

Check for NULL kmalloc return value before writing to it.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] TG3: ethtool always report port is TP.
Karsten Keil [Fri, 12 May 2006 19:49:08 +0000 (12:49 -0700)]
[PATCH] TG3: ethtool always report port is TP.

Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.

Signed-off-by: Karsten Keil <kkeil@suse.de>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Netfilter: do_add_counters race, possible oops or info leak (CVE-2006-0039)
Chris Wright [Tue, 16 May 2006 19:07:20 +0000 (12:07 -0700)]
[PATCH] Netfilter: do_add_counters race, possible oops or info leak (CVE-2006-0039)

Solar Designer found a race condition in do_add_counters(). The beginning
of paddc is supposed to be the same as tmp which was sanity-checked
above, but it might not be the same in reality. In case the integer
overflow and/or the race condition are triggered, paddc->num_counters
might not match the allocation size for paddc. If the check below
(t->private->number != paddc->num_counters) nevertheless passes (perhaps
this requires the race condition to be triggered), IPT_ENTRY_ITERATE()
would read kernel memory beyond the allocation size, potentially causing
an oops or leaking sensitive data (e.g., passwords from host system or
from another VPS) via counter increments.  This requires CAP_NET_ADMIN.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191698

Cc: Solar Designer <solar@openwall.com>
Cc: Kirill Korotaev <dev@sw.ru>
Cc: Patrick McHardy <kaber@trash.net>
(chrisw: rebase of Kirill's patch to 2.6.16.16)
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] scx200_acb: Fix resource name use after free
Jean Delvare [Sat, 13 May 2006 09:17:37 +0000 (11:17 +0200)]
[PATCH] scx200_acb: Fix resource name use after free

We can't pass a string on the stack to request_region. As soon as we
leave the function that stack is gone and the string is lost. Let's
use the same string we identify the i2c_adapter with instead, it's
more simple, more consistent, and just works.

This is the second half of fix to bug #6445.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] smbus unhiding kills thermal management
Carl-Daniel Hailfinger [Mon, 15 May 2006 16:44:33 +0000 (09:44 -0700)]
[PATCH] smbus unhiding kills thermal management

Do not enable the SMBus device on Asus boards if suspend is used.  We do
not reenable the device on resume, leading to all sorts of undesirable
effects, the worst being a total fan failure after resume on Samsung P35
laptop.

This fixes bug #6449 at bugzilla.kernel.org.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
11 years ago[PATCH] fs/compat.c: fix 'if (a |= b )' typo
Alexey Dobriyan [Mon, 15 May 2006 16:44:27 +0000 (09:44 -0700)]
[PATCH] fs/compat.c: fix 'if (a |= b )' typo

Mentioned by Mark Armbrust somewhere on Usenet.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] smbfs: Fix slab corruption in samba error path
Jan Niehusmann [Mon, 15 May 2006 16:44:12 +0000 (09:44 -0700)]
[PATCH] smbfs: Fix slab corruption in samba error path

Yesterday, I got the following error with 2.6.16.13 during a file copy from
a smb filesystem over a wireless link.  I guess there was some error on the
wireless link, which in turn caused an error condition for the smb
filesystem.

In the log, smb_file_read reports error=4294966784 (0xfffffe00), which also
shows up in the slab dumps, and also is -ERESTARTSYS.  Error code 27499
corresponds to 0x6b6b, so the rq_errno field seems to be the only one being
set after freeing the slab.

In smb_add_request (which is the only place in smbfs where I found
ERESTARTSYS), I found the following:

        if (!timeleft || signal_pending(current)) {
                /*
                 * On timeout or on interrupt we want to try and remove the
                 * request from the recvq/xmitq.
                 */
                smb_lock_server(server);
                if (!(req->rq_flags & SMB_REQ_RECEIVED)) {
                        list_del_init(&req->rq_queue);
                        smb_rput(req);
                }
                smb_unlock_server(server);
        }
[...]
        if (signal_pending(current))
                req->rq_errno = -ERESTARTSYS;

I guess that some codepath like smbiod_flush() caused the request to be
removed from the queue, and smb_rput(req) be called, without
SMB_REQ_RECEIVED being set.  This violates an asumption made by the quoted
code.

Then, the above code calls smb_rput(req) again, the req gets freed, and
req->rq_errno = -ERESTARTSYS writes into the already freed slab.  As
list_del_init doesn't cause an error if called multiple times, that does
cause the observed behaviour (freed slab with rq_errno=-ERESTARTSYS).

If this observation is correct, the following patch should fix it.

I wonder why the smb code uses list_del_init everywhere - using list_del
instead would catch such situations by poisoning the next and prev
pointers.

May  4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Firmware error detected.  Restarting.
May  4 23:29:21 knautsch kernel: [17180085.456000] ipw2200: Sysfs 'error' log captured.
May  4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Firmware error detected.  Restarting.
May  4 23:33:02 knautsch kernel: [17180306.316000] ipw2200: Sysfs 'error' log already exists.
May  4 23:33:02 knautsch kernel: [17180306.968000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:34:18 knautsch kernel: [17180383.256000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:34:18 knautsch kernel: [17180383.284000] SMB connection re-established (-5)
May  4 23:37:19 knautsch kernel: [17180563.956000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:40:09 knautsch kernel: [17180733.636000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:40:26 knautsch kernel: [17180750.700000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:02 knautsch kernel: [17180907.304000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:08 knautsch kernel: [17180912.324000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:43:34 knautsch kernel: [17180938.416000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:43:34 knautsch kernel: [17180938.416000] Slab corruption: start=c4ebe09c, len=244
May  4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.416000] 0f0: 00 fe ff ff
May  4 23:43:34 knautsch kernel: [17180938.416000] Next obj: start=c4ebe19c, len=244
May  4 23:43:34 knautsch kernel: [17180938.416000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:43:34 knautsch kernel: [17180938.416000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:43:34 knautsch kernel: [17180938.416000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.416000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:43:34 knautsch kernel: [17180938.460000] SMB connection re-established (-5)
May  4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Firmware error detected.  Restarting.
May  4 23:43:42 knautsch kernel: [17180946.292000] ipw2200: Sysfs 'error' log already exists.
May  4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Firmware error detected.  Restarting.
May  4 23:45:04 knautsch kernel: [17181028.752000] ipw2200: Sysfs 'error' log already exists.
May  4 23:45:05 knautsch kernel: [17181029.868000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:45:36 knautsch kernel: [17181060.984000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:45:36 knautsch kernel: [17181060.984000] Slab corruption: start=c4ebe09c, len=244
May  4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181060.984000] 0f0: 00 fe ff ff
May  4 23:45:36 knautsch kernel: [17181060.984000] Next obj: start=c4ebe19c, len=244
May  4 23:45:36 knautsch kernel: [17181060.984000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:45:36 knautsch kernel: [17181060.984000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:45:36 knautsch kernel: [17181060.984000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181060.984000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:45:36 knautsch kernel: [17181061.024000] SMB connection re-established (-5)
May  4 23:46:17 knautsch kernel: [17181102.132000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:47:46 knautsch kernel: [17181190.468000] smb_errno: class Unknown, code 27499 from command 0x6b
May  4 23:47:46 knautsch kernel: [17181190.468000] Slab corruption: start=c4ebe09c, len=244
May  4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<e087b903>](smb_rput+0x53/0x90 [smbfs])
May  4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.468000] 0f0: 00 fe ff ff
May  4 23:47:46 knautsch kernel: [17181190.468000] Next obj: start=c4ebe19c, len=244
May  4 23:47:46 knautsch kernel: [17181190.468000] Redzone: 0x5a2cf071/0x5a2cf071.
May  4 23:47:46 knautsch kernel: [17181190.468000] Last user: [<00000000>](_stext+0x3feffde0/0x30)
May  4 23:47:46 knautsch kernel: [17181190.468000] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.468000] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
May  4 23:47:46 knautsch kernel: [17181190.492000] SMB connection re-established (-5)
May  4 23:49:20 knautsch kernel: [17181284.828000] smb_file_read: //some_file validation failed, error=4294966784
May  4 23:49:39 knautsch kernel: [17181303.896000] smb_file_read: //some_file validation failed, error=4294966784

Signed-off-by: Jan Niehusmann <jan@gondor.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] fs/locks.c: Fix sys_flock() race
Trond Myklebust [Fri, 31 Mar 2006 10:30:55 +0000 (02:30 -0800)]
[PATCH] fs/locks.c: Fix sys_flock() race

sys_flock() currently has a race which can result in a double free in the
multi-thread case.

Thread 1 Thread 2

sys_flock(file, LOCK_EX)
sys_flock(file, LOCK_UN)

If Thread 2 removes the lock from inode->i_lock before Thread 1 tests for
list_empty(&lock->fl_link) at the end of sys_flock, then both threads will
end up calling locks_free_lock for the same lock.

Fix is to make flock_lock_file() do the same as posix_lock_file(), namely
to make a copy of the request, so that the caller can always free the lock.

This also has the side-effect of fixing up a reference problem in the
lockd handling of flock.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] USB: ub oops in block_uevent
Pete Zaitcev [Wed, 3 May 2006 07:16:00 +0000 (00:16 -0700)]
[PATCH] USB: ub oops in block_uevent

In kernel 2.6.16, if a mounted storage device is removed, an oops happens
because ub supplies an interface device (and kobject) to the block layer,
but neglects to pin it. And apparently, the block layer expects its users
to pin device structures.

The code in ub was broken this way for years. But the bug was exposed only
by 2.6.16 when it started to call block_uevent on close, which traverses
device structures (kobjects actually).

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards
Craig Brind [Tue, 2 May 2006 19:59:21 +0000 (19:59 +0000)]
[PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards

Fixes Rhine I cards disclosing fragments of previously transmitted frames
in new transmissions.

Before transmission, any socket buffer (skb) shorter than the ethernet
minimum length of 60 bytes was zero-padded.  On Rhine I cards the data can
later be copied into an aligned transmission buffer without copying this
padding.  This resulted in the transmission of the frame with the extra
bytes beyond the provided content leaking the previous contents of this
buffer on to the network.

Now zero-padding is repeated in the local aligned buffer if one is used.

Following a suggestion from the via-rhine maintainer, no attempt is made
here to avoid the duplicated effort of padding the skb if it is known that
an aligned buffer will definitely be used.  This is to make the change
"obviously correct" and allow it to be applied to a stable kernel if
necessary.  There is no change to the flow of control and the changes are
only to the Rhine I code path.

The patch has run on an in-service Rhine-I host without incident.  Frames
shorter than 60 bytes are now correctly zero-padded when captured on a
separate host.  I see no unusual stats reported by ifconfig, and no unusual
log messages.

Signed-off-by: Craig Brind <craigbrind@gmail.com>
Signed-off-by: Roger Luethi <rl@hellgate.ch>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] md: Avoid oops when attempting to fix read errors on raid10
NeilBrown [Mon, 1 May 2006 19:15:44 +0000 (12:15 -0700)]
[PATCH] md: Avoid oops when attempting to fix read errors on raid10

We should add to the counter for the rdev *after* checking if the rdev is
NULL!!!

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.16
Chris Wright [Thu, 11 May 2006 01:56:24 +0000 (18:56 -0700)]
Linux 2.6.16.16

11 years ago[PATCH] fs/locks.c: Fix lease_init (CVE-2006-1860)
Trond Myklebust [Mon, 8 May 2006 03:02:42 +0000 (23:02 -0400)]
[PATCH] fs/locks.c: Fix lease_init (CVE-2006-1860)

It is insane to be giving lease_init() the task of freeing the lock it is
supposed to initialise, given that the lock is not guaranteed to be
allocated on the stack. This causes lockups in fcntl_setlease().
Problem diagnosed by Daniel Hokka Zakrisson <daniel@hozac.com>

Also fix a slab leak in __setlease() due to an uninitialised return value.
Problem diagnosed by Björn Steinbrink.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Daniel Hokka Zakrisson <daniel@hozac.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Cc: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.15
Chris Wright [Tue, 9 May 2006 19:53:30 +0000 (12:53 -0700)]
Linux 2.6.16.15

11 years ago[PATCH] SCTP: Prevent possible infinite recursion with multiple bundled DATA. (CVE...
Vladislav Yasevich [Sat, 6 May 2006 00:03:49 +0000 (17:03 -0700)]
[PATCH] SCTP: Prevent possible infinite recursion with multiple bundled DATA. (CVE-2006-2274)

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] SCTP: Allow spillover of receive buffer to avoid deadlock. (CVE-2006-2275)
Neil Horman [Sat, 6 May 2006 00:02:09 +0000 (17:02 -0700)]
[PATCH] SCTP: Allow spillover of receive buffer to avoid deadlock. (CVE-2006-2275)

This patch fixes a deadlock situation in the receive path by allowing
temporary spillover of the receive buffer.

- If the chunk we receive has a tsn that immediately follows the ctsn,
  accept it even if we run out of receive buffer space and renege data with
  higher TSNs.
- Once we accept one chunk in a packet, accept all the remaining chunks
  even if we run out of receive buffer space.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Mark Butler <butlerm@middle.net>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] SCTP: Fix state table entries for chunks received in CLOSED state. (CVE-2006...
Sridhar Samudrala [Sat, 6 May 2006 00:05:23 +0000 (17:05 -0700)]
[PATCH] SCTP: Fix state table entries for chunks received in CLOSED state. (CVE-2006-2271)

Discard an unexpected chunk in CLOSED state rather can calling BUG().

Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] SCTP: Fix panic's when receiving fragmented SCTP control chunks. (CVE-2006...
Sridhar Samudrala [Sat, 6 May 2006 00:04:43 +0000 (17:04 -0700)]
[PATCH] SCTP: Fix panic's when receiving fragmented SCTP control chunks. (CVE-2006-2272)

Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
are received as skb's with fragment list.

Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.14
Chris Wright [Fri, 5 May 2006 00:03:45 +0000 (17:03 -0700)]
Linux 2.6.16.14

11 years ago[PATCH] smbfs chroot issue (CVE-2006-1864)
Olaf Kirch [Thu, 4 May 2006 04:30:11 +0000 (21:30 -0700)]
[PATCH] smbfs chroot issue (CVE-2006-1864)

Mark Moseley reported that a chroot environment on a SMB share can be
left via "cd ..\\".  Similar to CVE-2006-1863 issue with cifs, this fix
is for smbfs.

Steven French <sfrench@us.ibm.com> wrote:

Looks fine to me.  This should catch the slash on lookup or equivalent,
which will be all obvious paths of interest.

Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years agoLinux 2.6.16.13
Greg Kroah-Hartman [Tue, 2 May 2006 21:38:44 +0000 (14:38 -0700)]
Linux 2.6.16.13

11 years ago[PATCH] NETFILTER: SCTP conntrack: fix infinite loop (CVE-2006-1527)
Patrick McHardy [Tue, 2 May 2006 21:23:07 +0000 (23:23 +0200)]
[PATCH] NETFILTER: SCTP conntrack: fix infinite loop (CVE-2006-1527)

[NETFILTER]: SCTP conntrack: fix infinite loop

fix infinite loop in the SCTP-netfilter code: check SCTP chunk size to
guarantee progress of for_each_sctp_chunk(). (all other uses of
for_each_sctp_chunk() are preceded by do_basic_checks(), so this fix
should be complete.)

Based on patch from Ingo Molnar <mingo@elte.hu>

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years agoLinux 2.6.16.12
Greg Kroah-Hartman [Mon, 1 May 2006 19:14:26 +0000 (12:14 -0700)]
Linux 2.6.16.12

11 years ago[PATCH] i386: fix broken FP exception handling
Chuck Ebbert [Sat, 29 Apr 2006 18:07:49 +0000 (14:07 -0400)]
[PATCH] i386: fix broken FP exception handling

The FXSAVE information leak patch introduced a bug in FP exception
handling: it clears FP exceptions only when there are already
none outstanding.  Mikael Pettersson reported that causes problems
with the Erlang runtime and has tested this fix.

Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Acked-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] MIPS: Fix branch emulation for floating-point exceptions.
Win Treese [Wed, 26 Apr 2006 23:00:04 +0000 (00:00 +0100)]
[PATCH] MIPS: Fix branch emulation for floating-point exceptions.

In the branch emulation for floating-point exceptions, __compute_return_epc
must determine for bc1f et al which condition code bit to test. This is
based on bits <4:2> of the rt field. The switch statement to distinguish
bc1f et al needs to use only the two low bits of rt, but the old code tests
on the whole rt field.  This patch masks off the proper bits.

Signed-off-by: Win Treese <treese@acm.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] MIPS: Fix tx49_blast_icache32_page_indexed.
Atsushi Nemoto [Wed, 26 Apr 2006 23:00:03 +0000 (00:00 +0100)]
[PATCH] MIPS: Fix tx49_blast_icache32_page_indexed.

Fix the cache index value in tx49_blast_icache32_page_indexed().
This is damage by de62893bc0725f8b5f0445250577cd7a10b2d8f8 commit.

Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] MIPS: R2 build fixes for gcc < 3.4.
Ralf Baechle [Wed, 26 Apr 2006 23:00:02 +0000 (00:00 +0100)]
[PATCH] MIPS: R2 build fixes for gcc < 3.4.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] MIPS: Use "R" constraint for cache_op.
Ralf Baechle [Wed, 26 Apr 2006 23:00:01 +0000 (00:00 +0100)]
[PATCH] MIPS: Use "R" constraint for cache_op.

Gcc might emit an absolute address for the the "m" constraint which
gas unfortunately does not permit.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] NET: e1000: Update truesize with the length of the packet for packet split
Auke Kok [Wed, 26 Apr 2006 06:16:29 +0000 (23:16 -0700)]
[PATCH] NET: e1000: Update truesize with the length of the packet for packet split

Update skb with the real packet size.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case
Zachary Amsden [Thu, 27 Apr 2006 20:01:39 +0000 (20:01 +0000)]
[PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case

Proposed fix for ptep_get_and_clear_full PAE bug.  Pte_clear had the same bug,
so use the same fix for both.  Turns out pmd_clear had it as well, but pgds
are not affected.

The problem is rather intricate.  Page table entries in PAE mode are 64-bits
wide, but the only atomic 8-byte write operation available in 32-bit mode is
cmpxchg8b, which is expensive (at least on P4), and thus avoided.  But it can
happen that the processor may prefetch entries into the TLB in the middle of an
operation which clears a page table entry.  So one must always clear the P-bit
in the low word of the page table entry first when clearing it.

Since the sequence *ptep = __pte(0) leaves the order of the write dependent on
the compiler, it must be coded explicitly as a clear of the low word followed
by a clear of the high word.  Further, there must be a write memory barrier
here to enforce proper ordering by the compiler (and, in the future, by the
processor as well).

On > 4GB memory machines, the implementation of pte_clear for PAE was clearly
deficient, as it could leave virtual mappings of physical memory above 4GB
aliased to memory below 4GB in the TLB.  The implementation of
ptep_get_and_clear_full has a similar bug, although not nearly as likely to
occur, since the mappings being cleared are in the process of being destroyed,
and should never be dereferenced again.

But, as luck would have it, it is possible to trigger bugs even without ever
dereferencing these bogus TLB mappings, even if the clear is followed fairly
soon after with a TLB flush or invalidation.  The problem is that memory above
4GB may now be aliased into the first 4GB of memory, and in fact, may hit a
region of memory with non-memory semantics.  These regions include AGP and PCI
space.  As such, these memory regions are not cached by the processor.  This
introduces the bug.

The processor can speculate memory operations, including memory writes, as long
as they are committed with the proper ordering.  Speculating a memory write to
a linear address that has a bogus TLB mapping is possible.  Normally, the
speculation is harmless.  But for cached memory, it does leave the falsely
speculated cacheline unmodified, but in a dirty state.  This cache line will be
eventually written back.  If this cacheline happens to intersect a region of
memory that is not protected by the cache coherency protocol, it can corrupt
data in I/O memory, which is generally a very bad thing to do, and can cause
total system failure or just plain undefined behavior.

These bugs are extremely unlikely, but the severity is of such magnitude, and
the fix so simple that I think fixing them immediately is justified.  Also,
they are nearly impossible to debug.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] LSM: add missing hook to do_compat_readv_writev()
James Morris [Wed, 26 Apr 2006 15:11:00 +0000 (15:11 +0000)]
[PATCH] LSM: add missing hook to do_compat_readv_writev()

This patch addresses a flaw in LSM, where there is no mediation of readv()
and writev() in for 32-bit compatible apps using a 64-bit kernel.

This bug was discovered and fixed initially in the native readv/writev
code [1], but was not fixed in the compat code.  Thanks to Al for spotting
this one.

  [1] http://lwn.net/Articles/154282/

Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
11 years ago[PATCH] Alpha: strncpy() fix
Ivan Kokshaysky [Tue, 25 Apr 2006 14:59:34 +0000 (14:59 +0000)]
[PATCH] Alpha: strncpy() fix

As it turned out after recent SCSI changes, strncpy() was broken -
it mixed up the return values from __stxncpy() in registers $24 and $27.

Thanks to Mathieu Chouquet-Stringer for tracking down the problem
and providing an excellent test case.

Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Altix snsc: duplicate kobject fix
Greg Howard [Sun, 23 Apr 2006 17:10:42 +0000 (17:10 +0000)]
[PATCH] Altix snsc: duplicate kobject fix

Fix Altix system controller (snsc) device names to include the slot number
of the blade whose associated system controller is the target of the device
interface.  Including the slot number avoids a problem we're currently
having where slots within the same enclosure are attempting to create
multiple kobjects with identical names.

Signed-off-by: Greg Howard <ghoward@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Fix reiserfs deadlock
Jan Kara [Sun, 23 Apr 2006 17:10:44 +0000 (17:10 +0000)]
[PATCH] Fix reiserfs deadlock

reiserfs_cache_default_acl() should return whether we successfully found
the acl or not.  We have to return correct value even if reiserfs_get_acl()
returns error code and not just 0.  Otherwise callers such as
reiserfs_mkdir() can unnecessarily lock the xattrs and later functions such
as reiserfs_new_inode() fail to notice that we have already taken the lock
and try to take it again with obvious consequences.

Signed-off-by: Jan Kara <jack@suse.cz>
Cc: <reiserfs-dev@namesys.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Simplify proc/devices and fix early termination regression
Andrew Morton [Fri, 21 Apr 2006 08:51:36 +0000 (01:51 -0700)]
[PATCH] Simplify proc/devices and fix early termination regression

Repair /proc/devices early-termination regression.

2.6.16 broke /proc/devices.  An application often gets an
EOF before the end of data is reached, if that application
uses a series of short read(2)s to access the data.  I have
used read buffers of varying sizes with varying degrees
of unsuccess (larger sizes get further into the data than
smaller sizes, following a simple pattern).  It appears
that the only safe way to get the data is to use a single
read buffer larger than all the data in /proc/devices.

The following example demonstates the problem:

    # dd if=/proc/devices bs=1
    Character devices:
      1 mem
    27+0 records in
    27+0 records out

This patch is a backport of the fix recently accepted to
Linus's tree:

    commit 68eef3b4791572ecb70249c7fb145bb3742dd899
    [PATCH] Simplify proc/devices and fix early termination regression

It replaces the complex, state-machine algorithm introduced
in 2.6.16 with a simple algorithm, modeled on the implementation
of /proc/interrupts.

[akpm@osdl.org: cleanups, simplifications]

Signed-off-by: Joe Korty <joe.korty@ccur.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] dm flush queue EINTR
Jun'ichi Nomura [Mon, 27 Mar 2006 09:17:51 +0000 (01:17 -0800)]
[PATCH] dm flush queue EINTR

If dm_suspend() is cancelled, bios already added to the deferred list need to
be submitted.  Otherwise they remain 'in limbo' until there's a dm_resume().

Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] dm snapshot: fix kcopyd destructor
Alasdair G Kergon [Mon, 24 Apr 2006 20:36:06 +0000 (13:36 -0700)]
[PATCH] dm snapshot: fix kcopyd destructor

Before removing a snapshot, wait for the completion of any kcopyd jobs using
it.

Do this by maintaining a count (nr_jobs) of how many outstanding jobs each
kcopyd_client has.

The snapshot destructor first unregisters the snapshot so that no new kcopyd
jobs (created by writes to the origin) will reference that particular
snapshot.  kcopyd_client_destroy() is now run next to wait for the completion
of any outstanding jobs before the snapshot exception structures (that those
jobs reference) are freed.

Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] cxusb-bluebird: bug-fix: power down corrupts frontend
Michael Krufky [Sat, 22 Apr 2006 07:35:50 +0000 (03:35 -0400)]
[PATCH] cxusb-bluebird: bug-fix: power down corrupts frontend

This patch prevents a bug where the frontend is unable to tune after waking
from powered down state. Now, the device remains powered on until it is
disconnected, just like the windows driver. It seems that the bluebird
firmware is unable to successfully handle tuning after a powered down state.

This patch fixes all of the FusionHDTV Bluebird USB2 devices. The Medion
MD95700 will still behave as before, since it was unaffected by this bug.

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] fix saa7129 support in saa7127 module for pvr350 tv out
Jose Alberto Reguero [Sat, 22 Apr 2006 07:35:45 +0000 (03:35 -0400)]
[PATCH] fix saa7129 support in saa7127 module for pvr350 tv out

This patch fixes tv-out support for the newer model of
the pvr350, which has a saa7129 instead of a saa7127
video encoder.

Signed-off-by: Jose Alberto Reguero <jareguero@telefonica.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] for_each_possible_cpu
Andrew Morton [Mon, 24 Apr 2006 08:49:59 +0000 (01:49 -0700)]
[PATCH] for_each_possible_cpu

Backport for_each_possible_cpu() into 2.6.16.  Fixes the alpha build, and any
future occurrences.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] get_dvb_firmware: download nxt2002 firmware from new driver location
Michael Krufky [Sun, 23 Apr 2006 06:16:42 +0000 (02:16 -0400)]
[PATCH] get_dvb_firmware: download nxt2002 firmware from new driver location

BBTI has updated their driver, and removed the old one from their website.
This patch updates the get_dvb_firmware script to download the firmware
from the new driver location.

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] tipar oops fix
Daniel Drake [Sun, 23 Apr 2006 22:43:59 +0000 (15:43 -0700)]
[PATCH] tipar oops fix

If compiled into the kernel, parport_register_driver() is called before the
parport driver has been initalised.

This means that it is expected that tp_count is 0 after the
parport_register_driver() call() - tipar's attach function will not be
called until later during bootup.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] USB: fix array overrun in drivers/usb/serial/option.c
Eric Sesterhenn [Sun, 23 Apr 2006 20:52:28 +0000 (22:52 +0200)]
[PATCH] USB: fix array overrun in drivers/usb/serial/option.c

since the arrays are declared as in_urbs[N_IN_URB]
and out_urbs[N_OUT_URB] both for loops, go one
over the end of the array. This fixes coverity id #555

This patch was already included in Linus' tree.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86_64: Fix a race in the free_iommu path.
Mike Waychison [Fri, 21 Apr 2006 07:43:25 +0000 (09:43 +0200)]
[PATCH] x86_64: Fix a race in the free_iommu path.

We do this by removing a micro-optimization that tries to avoid grabbing
the iommu_bitmap_lock spinlock and using a bus-locked operation.

This still races with other simultaneous alloc_iommu or free_iommu(size
> 1) which both use bus-unlocked operations.

The end result of this race is eventually ending
up with an iommu_gart_bitmap that has bits errornously set all over,
making large contiguous iommu space allocations fail with 'PCI-DMA:
Out of IOMMU space'.

Signed-off-by: Mike Waychison <mikew@google.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86_64: Pass -32 to the assembler when compiling the 32bit vsyscall pages
Andi Kleen [Fri, 21 Apr 2006 07:43:22 +0000 (09:43 +0200)]
[PATCH] x86_64: Pass -32 to the assembler when compiling the 32bit vsyscall pages

This quietens warnings and actually fixes a bug. The unwind tables would
come out wrong without -32, causing pthread cancellation during them
to crash in the gcc runtime.

The problem seems to only happen with newer binutils
(it doesn't happen with 2.16.91.0.2 but happens wit 2.16.91.0.5)

Thanks to Brian Baker @ HP for test case and initial analysis.

Cc: brian.b@hp.com
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] make vm86 call audit_syscall_exit
Jason Baron [Tue, 31 Jan 2006 21:56:28 +0000 (16:56 -0500)]
[PATCH] make vm86 call audit_syscall_exit

hi,

The motivation behind the patch below was to address messages in
/var/log/messages such as:

Jan 31 10:54:15 mets kernel: audit(:0): major=252 name_count=0: freeing
multiple contexts (1)
Jan 31 10:54:15 mets kernel: audit(:0): major=113 name_count=0: freeing
multiple contexts (2)

I can reproduce by running 'get-edid' from:
http://john.fremlin.de/programs/linux/read-edid/.

These messages come about in the log b/c the vm86 calls do not exit via
the normal system call exit paths and thus do not call
'audit_syscall_exit'. The next system call will then free the context for
itself and for the vm86 context, thus generating the above messages. This
patch addresses the issue by simply adding a call to 'audit_syscall_exit'
from the vm86 code.

Besides fixing the above error messages the patch also now allows vm86
system calls to become auditable. This is useful since strace does not
appear to properly record the return values from sys_vm86.

I think this patch is also a step in the right direction in terms of
cleaning up some core auditing code. If we can correct any other paths
that do not properly call the audit exit and entries points, then we can
also eliminate the notion of context chaining.

I've tested this patch by verifying that the log messages no longer
appear, and that the audit records for sys_vm86 appear to be correct.
Also, 'read_edid' produces itentical output.

thanks,

-Jason

Signed-off-by: Jason Baron <jbaron@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] cs5535_gpio.c: call cdev_del() during module_exit to unmap kobject references...
Thayumanavar Sachithanantham [Thu, 20 Apr 2006 16:00:56 +0000 (16:00 +0000)]
[PATCH] cs5535_gpio.c: call cdev_del() during module_exit to unmap kobject references and other cleanups

During module unloading, cdev_del() must be called to unmap cdev related
kobject references and other cleanups(such as inode->i_cdev being set to
NULL) which prevents the OOPS upon subsequent loading, usage and unloading
of modules(as seen in the mail thread
http://marc.theaimsgroup.com/?l=linux-kernel&m=114533640609018&w=2).

Also, remove unneeded test of gpio_base.

Signed-off-by: Thayumanavar Sachithanantham <thayumk@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] sonypi: correct detection of new ICH7-based laptops
Arnaud MAZIN [Thu, 20 Apr 2006 16:01:02 +0000 (16:01 +0000)]
[PATCH] sonypi: correct detection of new ICH7-based laptops

Add a test to detect the ICH7 based Core Duo SONY laptops (such as the SZ1)
as type3 models.

Signed-off-by: Arnaud MAZIN <arnaud.mazin@gmail.com>
Acked-by: Stelian Pop <stelian@poppies.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years agoLinux 2.6.16.11
Greg Kroah-Hartman [Mon, 24 Apr 2006 20:20:24 +0000 (13:20 -0700)]
Linux 2.6.16.11

11 years ago[PATCH] Don't allow a backslash in a path component (CVE-2006-1863)
Steve French [Fri, 21 Apr 2006 18:18:37 +0000 (18:18 +0000)]
[PATCH] Don't allow a backslash in a path component (CVE-2006-1863)

Unless Posix paths have been negotiated, the backslash, "\", is not a valid
character in a path component.

Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years agoLinux 2.6.16.10
Greg Kroah-Hartman [Mon, 24 Apr 2006 17:07:37 +0000 (10:07 -0700)]
Linux 2.6.16.10

11 years ago[PATCH] IPC: access to unmapped vmalloc area in grow_ary()
Alexey Kuznetsov [Tue, 18 Apr 2006 03:04:00 +0000 (03:04 +0000)]
[PATCH] IPC: access to unmapped vmalloc area in grow_ary()

grow_ary() should not copy struct ipc_id_ary (it copies new->p, not
new). Due to this, memcpy() src pointer could hit unmapped vmalloc page
when near page boundary.

Found during OpenVZ stress testing

Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Add more prevent_tail_call()
OGAWA Hirofumi [Wed, 19 Apr 2006 23:59:40 +0000 (23:59 +0000)]
[PATCH] Add more prevent_tail_call()

Those also break userland regs like following.

   00000000 <sys_chown16>:
      0: 0f b7 44 24 0c        movzwl 0xc(%esp),%eax
      5: 83 ca ff              or     $0xffffffff,%edx
      8: 0f b7 4c 24 08        movzwl 0x8(%esp),%ecx
      d: 66 83 f8 ff           cmp    $0xffffffff,%ax
     11: 0f 44 c2              cmove  %edx,%eax
     14: 66 83 f9 ff           cmp    $0xffffffff,%cx
     18: 0f 45 d1              cmovne %ecx,%edx
     1b: 89 44 24 0c           mov    %eax,0xc(%esp)
     1f: 89 54 24 08           mov    %edx,0x8(%esp)
     23: e9 fc ff ff ff        jmp    24 <sys_chown16+0x24>

where the tailcall at the end overwrites the incoming stack-frame.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] alim15x3: ULI M-1573 south Bridge support
KAI.HSU [Wed, 19 Apr 2006 17:01:17 +0000 (17:01 +0000)]
[PATCH] alim15x3: ULI M-1573 south Bridge support

>From http://bugzilla.kernel.org/show_bug.cgi?id=6358

The alim15x3.c havn't been update for 3 years.  Recently when we use this
"ULI M1573" south bridge chip found that can't mount CDROM(VCD) smoothly,
must waiting for a long time.  After I check the "ULI M1573" south bridge
datasheet, I found the reason.  The reason is the "ULI M1573" version in
the Linux is "0xC7" not "0xC4" anymore So I was modified the source than it
was successed.

Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] apm: fix Armada laptops again
Samuel Thibault [Wed, 19 Apr 2006 17:00:54 +0000 (17:00 +0000)]
[PATCH] apm: fix Armada laptops again

Fix the "apm: set display: Interface not engaged" error on Armada laptops
again.

Jordan said:

  I think this is fine.  It seems to me that this may be the fault of one or
  both of the APM solutions handling this situation in a non-standard way, but
  since APM is used very little on the Geode, and I have direct access to our
  BIOS folks, if this problem comes up with a customer again, we'll solve it
  from the firmware.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: "Jordan Crouse" <jordan.crouse@amd.com>
Cc: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] fbdev: Fix return error of fb_write
Antonino A. Daplas [Wed, 19 Apr 2006 17:01:21 +0000 (17:01 +0000)]
[PATCH] fbdev: Fix return error of fb_write

Fix return code of fb_write():

If at least 1 byte was transferred to the device, return number of bytes,
otherwise:

    - return -EFBIG - if file offset is past the maximum allowable offset or
      size is greater than framebuffer length
    - return -ENOSPC - if size is greater than framebuffer length - offset

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Fix file lookup without ref
Dipankar Sarma [Wed, 19 Apr 2006 17:00:12 +0000 (17:00 +0000)]
[PATCH] Fix file lookup without ref

There are places in the kernel where we look up files in fd tables and
access the file structure without holding refereces to the file.  So, we
need special care to avoid the race between looking up files in the fd
table and tearing down of the file in another CPU.  Otherwise, one might
see a NULL f_dentry or such torn down version of the file.  This patch
fixes those special places where such a race may happen.

Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
Acked-by: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] m41t00: fix bitmasks when writing to chip
David Barksdale [Wed, 19 Apr 2006 16:59:54 +0000 (16:59 +0000)]
[PATCH] m41t00: fix bitmasks when writing to chip

Fix the bitmasks used when writing to the M41T00 registers.

The original code used a mask of 0x7f when writing to each register,
this is incorrect and probably the result of a copy-paste error.  As a
result years from 1980 to 1999 will be read back as 2000 to 2019.

Signed-off-by: David Barksdale <amatus@ocgnet.org>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] Open IPMI BT overflow
Heikki Orsila [Wed, 19 Apr 2006 17:01:01 +0000 (17:01 +0000)]
[PATCH] Open IPMI BT overflow

I was looking into random driver code and found a suspicious looking
memcpy() in drivers/char/ipmi/ipmi_bt_sm.c on 2.6.17-rc1:

if ((size < 2) || (size > IPMI_MAX_MSG_LENGTH))
return -1;
...
memcpy(bt->write_data + 3, data + 1, size - 1);

where sizeof bt->write_data is IPMI_MAX_MSG_LENGTH.  It looks like the
memcpy would overflow by 2 bytes if size == IPMI_MAX_MSG_LENGTH.  A patch
attached to limit size to (IPMI_MAX_LENGTH - 2).

Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86: be careful about tailcall breakage for sys_open[at] too
Linus Torvalds [Tue, 18 Apr 2006 20:59:27 +0000 (20:59 +0000)]
[PATCH] x86: be careful about tailcall breakage for sys_open[at] too

x86: be careful about tailcall breakage for sys_open[at] too

Came up through a quick grep for other cases similar to the ftruncate()
one in commit 0a489cb3b6a7b277030cdbc97c2c65905db94536.

Also, add a comment, so that people who read the code understand why we
do what looks like a no-op.

(Again, this won't actually matter to any sane user, since libc will
save and restore the register gcc stomps on, but it's still wrong to
stomp on it)

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] x86: don't allow tail-calls in sys_ftruncate[64]()
Linus Torvalds [Tue, 18 Apr 2006 20:59:26 +0000 (20:59 +0000)]
[PATCH] x86: don't allow tail-calls in sys_ftruncate[64]()

x86: don't allow tail-calls in sys_ftruncate[64]()

Gcc thinks it owns the incoming argument stack, but that's not true for
"asmlinkage" functions, and it corrupts the caller-set-up argument stack
when it pushes the third argument onto the stack.  Which can result in
%ebx getting corrupted in user space.

Now, normally nobody sane would ever notice, since libc will save and
restore %ebx anyway over the system call, but it's still wrong.

I'd much rather have "asmlinkage" tell gcc directly that it doesn't own
the stack, but no such attribute exists, so we're stuck with our hacky
manual "prevent_tail_call()" macro once more (we've had the same issue
before with sys_waitpid() and sys_wait4()).

Thanks to Hans-Werner Hilse <hilse@sub.uni-goettingen.de> for reporting
the issue and testing the fix.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] IPV6: XFRM: Fix decoding session with preceding extension header(s).
YOSHIFUJI Hideaki / \e$B5HF#1QL@\e(B [Wed, 19 Apr 2006 02:14:23 +0000 (11:14 +0900)]
[PATCH] IPV6: XFRM: Fix decoding session with preceding extension header(s).

[IPV6] XFRM: Fix decoding session with preceding extension header(s).

We did not correctly decode session with preceding extension
header(s).  This was because we had already pulled preceding
headers, skb->nh.raw + 40 + 1 - skb->data was minus, and
pskb_may_pull() failed.

We now have IP6CB(skb)->nhoff and skb->h.raw, and we can
start parsing / decoding upper layer protocol from current
position.

Tracked down by Noriaki TAKAMIYA <takamiya@po.ntts.co.jp>
and tested by Kazunori Miyazawa <kazunori@miyazawa.org>.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] IPV6: XFRM: Don't use old copy of pointer after pskb_may_pull().
YOSHIFUJI Hideaki / \e$B5HF#1QL@\e(B [Wed, 19 Apr 2006 02:14:07 +0000 (11:14 +0900)]
[PATCH] IPV6: XFRM: Don't use old copy of pointer after pskb_may_pull().

[IPV6] XFRM: Don't use old copy of pointer after pskb_may_pull().

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] IPV6: Ensure to have hop-by-hop options in our header of &sk_buff.
YOSHIFUJI Hideaki / \e$B5HF#1QL@\e(B [Wed, 19 Apr 2006 02:13:58 +0000 (11:13 +0900)]
[PATCH] IPV6: Ensure to have hop-by-hop options in our header of &sk_buff.

[IPV6]: Ensure to have hop-by-hop options in our header of &sk_buff.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
11 years ago[PATCH] selinux: Fix MLS compatibility off-by-one bug
Ron Yorston [Wed, 19 Apr 2006 05:21:04 +0000 (22:21 -0700)]
[PATCH] selinux: Fix MLS compatibility off-by-one bug

Fix an off-by-one error in the MLS compatibility code that was causing
contexts with a MLS suffix to be rejected, preventing sharing partitions
between FC4 and FC5.  Bug reported in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188068

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>