linux/drivers/char, branch v2.6.16.54

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

2007-04-20T22:18:01Z

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 Signed-off-by: Adrian Bunk

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

2007-03-11T06:39:14Z

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: Adrian Bunk

read_zero_pagealigned() locking fix

2007-01-23T15:46:22Z

Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by: Hugh Dickins Signed-off-by: Adrian Bunk

rtc: lockdep fix/workaround

2007-01-09T02:23:35Z

BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted) [] show_trace_log_lvl+0x58/0x171 [] show_trace+0xd/0x10 [] dump_stack+0x19/0x1b [] trace_hardirqs_on+0xa2/0x11e [] _spin_unlock_irq+0x22/0x26 [] rtc_get_rtc_time+0x32/0x176 [] hpet_rtc_interrupt+0x92/0x14d [] handle_IRQ_event+0x20/0x4d [] __do_IRQ+0x94/0xef [] do_IRQ+0x9e/0xbd [] common_interrupt+0x25/0x2c DWARF2 unwinder stuck at common_interrupt+0x25/0x2c Signed-off-by: Peter Zijlstra Signed-off-by: Adrian Bunk

rio: typo in bitwise AND expression.

2007-01-09T02:23:31Z

The line: hp->Mode &= !RIO_PCI_INT_ENABLE; is obviously wrong as RIO_PCI_INT_ENABLE=0x04 and is used as a bitmask 2 lines before. Getting no IRQ would not disable RIO_PCI_INT_ENABLE but rather RIO_PCI_BOOT_FROM_RAM which equals 0x01. Obvious fix is to change ! for ~. Signed-off-by: Willy Tarreau Signed-off-by: Adrian Bunk

drm: allow detection of new VIA chipsets

2007-01-09T02:23:31Z

Update pci ids. Signed-off-by: Chuck Short Signed-off-by: Ben Collins Signed-off-by: Adrian Bunk

drm: Add the P4VM800PRO PCI ID.

2007-01-09T02:23:31Z

Signed-off-by: Dave Airlie Signed-off-by: Adrian Bunk

hvc_console suspend fix

2006-12-17T23:39:11Z

Fix http://bugzilla.kernel.org/show_bug.cgi?id=7152 Signed-off-by: Andrew Morton Signed-off-by: Adrian Bunk

[WATCHDOG] sc1200wdt.c pnp unregister fix.

2006-12-17T23:23:42Z

If no devices found or invalid parameter is specified, scl200wdt_pnp_driver is left unregistered. It breaks global list of pnp drivers. Signed-off-by: Akinobu Mita Signed-off-by: Adrian Bunk

[WATCHDOG] sc1200wdt.c printk fix

2006-12-17T23:13:47Z

Fix printk output. sc1200wdt: build 20020303<3>sc1200wdt: io parameter must be specified Signed-off-by: Dave Jones Signed-off-by: Adrian Bunk