linux-toradex.git/drivers/char, branch v2.6.20.2

Fix buffer overflow in Omnikey CardMan 4040 driver (CVE-2007-0005)

2007-03-09T18:50:32+00:00

Based on a patch from Don Howard 

When calling write() with a buffer larger than 512 bytes, the
driver's write buffer overflows, allowing to overwrite the EIP and
execute arbitrary code with kernel privileges.

In read(), there exists a similar problem, but coming from the device.
A malicous or buggy device sending more than 512 bytes can overflow
of the driver's read buffer, with the same effects as above.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Harald Welte 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright

Char: specialix, isr have 2 params

2007-03-09T18:50:30+00:00

specialix, isr have 2 params

pt_regs are no longer the third parameter of isr, call sx_interrupt without
it.

Signed-off-by: Jiri Slaby 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

tty_io: fix race in master pty close/slave pty close path

2007-03-09T18:50:27+00:00

This patch fixes a possible race that leads to double freeing an idr index.
 When the master begin to close, release_dev() is called and then
pty_close() is called:

        if (tty->driver->close)
                tty->driver->close(tty, filp);

This is done without helding any locks other than BKL.  Inside pty_close(),
being a master close, the devpts entry will be removed:

#ifdef CONFIG_UNIX98_PTYS
                if (tty->driver == ptm_driver)
                        devpts_pty_kill(tty->index);
#endif

But devpts_pty_kill() will call get_node() that may sleep while waiting for
&devpts_root->d_inode->i_sem.  When this happens and the slave is being
opened, tty_open() just found the driver and index:

        driver = get_tty_driver(device, &index);
        if (!driver) {
                mutex_unlock(&tty_mutex);
                return -ENODEV;
        }

This part of the code is already protected under tty_mute.  The problem is
that the slave close already got an index.  Then init_dev() is called and
blocks waiting for the same &devpts_root->d_inode->i_sem.

When the master close resumes, it removes the devpts entry, and the
relation between idr index and the tty is gone.  The master then sleeps
waiting for the tty_mutex on release_dev().

Slave open resumes and found no tty for that index.  As result, a NULL tty
is returned and init_dev() doesn't flow to fast_track:

        /* check whether we're reopening an existing tty */
        if (driver->flags & TTY_DRIVER_DEVPTS_MEM) {
                tty = devpts_get_tty(idx);
                if (tty && driver->subtype == PTY_TYPE_MASTER)
                        tty = tty->link;
        } else {
                tty = driver->ttys[idx];
        }
        if (tty) goto fast_track;

The result of this, is that a new tty will be created and init_dev() returns
sucessfull. After returning, tty_mutex is dropped and master close may resume.

Master close finds it's the only use and both sides are closing, then releases
the tty and the index. At this point, the idr index is free, but slave still
has it.

Slave open then calls pty_open() and finds that tty->link->count is 0,
because there's no master and returns error.  Then tty_open() calls
release_dev() which executes without any warning, as it was a case of last
slave close when the master is already closed (master->count == 0,
slave->count == 1).  The tty is then released with the already released idr
index.

This normally would only issue a warning on idr_remove() but in case of a
customer's critical application, it's never too simple:

thread1: opens master, gets index X
thread1: begin closing master
thread2: begin opening slave with index X
thread1: finishes closing master, index X released
thread3: opens master, gets index X, just released
thread2: fails opening slave, releases index X         <----
thread4: opens master, gets index X, init_dev() then find an already in use
	 and healthy tty and fails

If no more indexes are released, ptmx_open() will keep failing, as the
first free index available is X, and it will make init_dev() fail because
you're trying to "reopen a master" which isn't valid.

The patch notices when this race happens and make init_dev() fail
imediately.  The init_dev() function is called with tty_mutex held, so it's
safe to continue with tty till the end of function because release_dev()
won't make any further changes without grabbing the tty_mutex.

Without the patch, on some machines it's possible get easily idr warnings
like this one:

idr_remove called for id=15 which is not allocated.
 [] idr_remove+0x139/0x170
 [] release_mem+0x182/0x230
 [] release_dev+0x4b7/0x700
 [] tty_ldisc_enable+0x27/0x30
 [] init_dev+0x254/0x580
 [] check_tty_count+0x14/0xb0
 [] tty_open+0x1c5/0x340
 [] tty_open+0x0/0x340
 [] chrdev_open+0xaf/0x180
 [] open_namei+0x8c/0x760
 [] chrdev_open+0x0/0x180
 [] __dentry_open+0xc9/0x210
 [] do_filp_open+0x5c/0x70
 [] get_unused_fd+0x61/0xd0
 [] do_sys_open+0x53/0x100
 [] sys_open+0x27/0x30
 [] syscall_call+0x7/0xb

using this test application available on:
 http://www.ruivo.org/~aris/pty_sodomizer.c

Signed-off-by: Aristeu Sergio Rozanski Filho 
Cc: "H. Peter Anvin" 
Cc: Chuck Ebbert 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

AGP: intel-agp bugfix

2007-03-09T18:50:18+00:00

On Sun, Feb 04, 2007 at 04:51:38PM +0100, Eric Piel wrote:
 > Hello,
 > 
 > I've got a regression in 2.6.20-rc7 (-rc6 was fine) due to commit 
 > 4b95320fc4d21b0ff2f8604305dd6c851aff6096 ([AGPGART] intel_agp: restore 
 > graphics device's pci space early in resume).

I think the key to this failure is the last line here ..

 > agpgart-intel 0000:00:00.0: resuming
 > PM: Writing back config space on device 0000:00:02.0 at offset f (was 10b, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset d (was dc, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset b (was 10161025, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset 5 (was f4000000, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset 4 (was f8000008, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset 2 (was 3000011, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset 1 (was 2b00007, writing 0)
 > PM: Writing back config space on device 0000:00:02.0 at offset 0 (was 11328086, writing 0)
 > agpgart: Unable to remap memory.

This then blows up the next access to intel_i810_private.registers, which happens to
be intel_i810_insert_entries.

Either we need .suspend methods which unmap these regions, or we need
to skip trying to map them a second time on resume.

There's an ugly patch below which does the latter. Give it a try?

The intel-agp suspend/resume code has really grown into something
of a monster, and could use some refactoring in a big way.

		Dave


From: Dave Jones 
Signed-off-by: Greg Kroah-Hartman

[PATCH] sysrq: showBlockedTasks is sysrq-W

2007-02-02T00:22:42+00:00

Change SysRq showBlockedTasks from sysrq-X to sysrq-W and show that in the
Help message.

It was previously done via X, but X is already used for Xmon on ppc & powerpc
platforms and this collision needs to be avoided.

All callers of register_sysrq_key() are now marked in the sysrq op/key table.
I didn't mark 'h' as Help because Help is just printed for any unknown key,
such as '?'.

Added some omitted sysrq key entries in the sysrq.txt file.

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] IPMI: fix timeout list handling

2007-01-31T00:01:36+00:00

Fix a dangling pointer bug in ipmi_timeout_handler.  A list of timedout
messages is not re-initialized before reuse, causing the head of the list
to point to freed memory.

Signed-off-by: David Barksdale 
Signed-off-by: Corey Minyard 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart

2007-01-30T16:43:26+00:00

* master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart:
  [AGPGART] Add new IDs to VIA AGP.
  [AGPGART] Remove pointless assignment.
  [AGPGART] Remove pointless typedef in ati-agp
  [AGPGART] Prevent (unlikely) memory leak in amd_create_gatt_pages()
  [AGPGART] intel_agp: restore graphics device's pci space early in resume

[AGPGART] Add new IDs to VIA AGP.

2007-01-28T22:58:33+00:00

Culled from the VIA codedrop.
Also fixes up one ID used in amd64-agp to use the
VIA part number instead of the board name in its ID.

Signed-off-by: Dave Jones

[AGPGART] Remove pointless assignment.

2007-01-28T22:50:17+00:00

No point in clearing local pointers then returning.
Also fix up some CodingStyle nits.

Signed-off-by: Dave Jones

[AGPGART] Remove pointless typedef in ati-agp

2007-01-28T22:41:37+00:00

This seems to exist just to save people typing 'struct' a few times,
and doesn't provide any additional value.

Signed-off-by: Dave Jones