linux/drivers/char, branch v2.6.20.15

[PATCH] random: fix seeding with zero entropy (CVE-2007-2453 2 of 2)

2007-06-07T21:23:04Z

Add data from zero-entropy random_writes directly to output pools to avoid accounting difficulties on machines without entropy sources. Tested on lguest with all entropy sources disabled. Signed-off-by: Matt Mackall Acked-by: "Theodore Ts'o" Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] random: fix error in entropy extraction (CVE-2007-2453 1 of 2)

2007-06-07T21:23:04Z

Fix cast error in entropy extraction. Add comments explaining the magic 16. Remove extra confusing loop variable. Signed-off-by: Matt Mackall Acked-by: "Theodore Ts'o" Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

AGPGART: intel_agp: fix G965 GTT size detect

2007-05-02T00:06:03Z

[AGPGART] intel_agp: fix G965 GTT size detect On G965, I810_PGETBL_CTL is a mmio offset, but we wrongly take it as pci config space offset in detecting GTT size. This one line patch fixs this. Signed-off-by: Wang Zhenyu Signed-off-by: Dave Jones Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

fix bogon in /dev/mem mmap'ing on nommu

2007-05-02T00:06:00Z

While digging through my MAP_FIXED changes, I found that rather obvious bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area() is expected to return an address, not a pfn. Signed-off-by: Benjamin Herrenschmidt Acked-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

vt: fix potential race in VT_WAITACTIVE handler

2007-05-02T00:06:00Z

[PATCH] vt: fix potential race in VT_WAITACTIVE handler On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 if fg_console has already been updated in redraw_screen() but the console switch itself hasn't been completed. Fix this by checking fg_console in vt_waitactive() with the console sem held. Signed-off-by: Michal Januszewski Acked-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

generic_serial: fix decoding of baud rate

2007-04-06T10:43:17Z

Commit d720bc4b8fc5d6d179ef094908d4fbb5e436ffad partially removed a private implementation of baud speed decoding. However it doesn't seem to be complete: after the speed is decoded, it is still being used as an index to a local speed table (array overrun, no doubt). This was found by Graham Murray who noticed it caused a 2.6.19 regression with the SX driver: https://bugs.gentoo.org/170554 Signed-off-by: Daniel Drake Acked-by: Alan Cox Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

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

2007-03-09T18:50:32Z

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:30Z

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:27Z

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:18Z

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