Skip to content

L
linux
Switch branch/tag
  1. 09 Jan, 2007 7 commits
  3. 04 Jan, 2007 6 commits
    • Linus Torvalds's avatar
      i386: save/restore eflags in context switch (CVE-2006-5173) · 09d9056c
      Linus Torvalds authored 
      (And reset it on new thread creation)

It turns out that eflags is important to save and restore not just
because of iopl, but due to the magic bits like the NT bit, which we
don't want leaking between different threads.

Backported to 2.6.16 by Chuck Ebbert <76306.1226@compuserve.com>
[Backport consisted of removing the CFI annotations.]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      09d9056c
    • Marcel Holtmann's avatar
      Call init_timer() for ISDN PPP CCP reset state timer (CVE-2006-5749) · bb3e712f
      Marcel Holtmann authored 
      The function isdn_ppp_ccp_reset_alloc_state() sets ->timer.function
and ->timer.data and later on calls add_timer() with no init_timer()
ever done.

Noted by Al Viro.
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      bb3e712f
    • Linus Torvalds's avatar
      Fix incorrect user space access locking in mincore() (CVE-2006-4814) · 7c876d45
      Linus Torvalds authored 
      Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no.  While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.

Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.

Also included are two fixes for the original patch including one
by Oleg Nesterov.
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      7c876d45
    • Miklos Szeredi's avatar
      fuse: fix hang on SMP · 571525bb
      Miklos Szeredi authored 
      Fuse didn't always call i_size_write() with i_mutex held which caused
rare hangs on SMP/32bit.  This bug has been present since fuse-2.2,
well before being merged into mainline.

The simplest solution is to protect i_size_write() with the
per-connection spinlock.  Using i_mutex for this purpose would require
some restructuring of the code and I'm not even sure it's always safe
to acquire i_mutex in all places i_size needs to be set.

Since most of vmtruncate is already duplicated for other reasons,
duplicate the remaining part as well, making all i_size_write() calls
internal to fuse.

Using i_size_write() was unnecessary in fuse_init_inode(), since this
function is only called on a newly created locked inode.

Reported by a few people over the years, but special thanks to Dana
Henriksen who was persistent enough in helping me debug it.

Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      571525bb
    • Robert Olsson's avatar
      [PKTGEN]: Fix module load/unload races. · e79366b5
      Robert Olsson authored 
      Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      e79366b5
    • Dirk Eibach's avatar
      i2c: fix broken ds1337 initialization · 51b73a03
      Dirk Eibach authored 
      On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.

The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.

Broken by commit f9e89579 (2.6.16-rc1,
2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit
763d9c04).
Signed-off-by: default avatarDirk Stieler <stieler@gdsys.de>
Signed-off-by: default avatarDirk Eibach <eibach@gdsys.de>
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      51b73a03
  5. 03 Jan, 2007 1 commit
    • Patrick McHardy's avatar
      NET_SCHED: Fix fallout from dev->qdisc RCU change · 83d285a2
      Patrick McHardy authored 
      The move of qdisc destruction to a rcu callback broke locking in the
entire qdisc layer by invalidating previously valid assumptions about
the context in which changes to the qdisc tree occur.

The two assumptions were:

- since changes only happen in process context, read_lock doesn't need
  bottem half protection. Now invalid since destruction of inner qdiscs,
  classifiers, actions and estimators happens in the RCU callback unless
  they're manually deleted, resulting in dead-locks when read_lock in
  process context is interrupted by write_lock_bh in bottem half context.

- since changes only happen under the RTNL, no additional locking is
  necessary for data not used during packet processing (f.e. u32_list).
  Again, since destruction now happens in the RCU callback, this assumption
  is not valid anymore, causing races while using this data, which can
  result in corruption or use-after-free.

Instead of "fixing" this by disabling bottem halfs everywhere and adding
new locks/refcounting, this patch makes these assumptions valid again by
moving destruction back to process context. Since only the dev->qdisc
pointer is protected by RCU, but ->enqueue and the qdisc tree are still
protected by dev->qdisc_lock, destruction of the tree can be performed
immediately and only the final free needs to happen in the rcu callback
to make sure dev_queue_xmit doesn't access already freed memory.
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      83d285a2
  7. 26 Dec, 2006 1 commit
  9. 18 Dec, 2006 4 commits
  11. 17 Dec, 2006 11 commits
  13. 15 Dec, 2006 5 commits
    • Linus Torvalds's avatar
      AGP: Allocate AGP pages with GFP_DMA32 by default · dcc6e343
      Linus Torvalds authored 
      Not all graphic page remappers support physical addresses over the 4GB
mark for remapping, so while some do (the AMD64 GART always did, and I
just fixed the i965 to do so properly), we're safest off just forcing
GFP_DMA32 allocations to make sure graphics pages get allocated in the
low 32-bit address space by default.

AGP sub-drivers that really care, and can do better, could just choose
to implement their own allocator (or we could add another "64-bit safe"
default allocator for their use), but quite frankly, you're not likely
to care in practice.

So for now, this trivial change means that we won't be allocating pages
that we can't map correctly by mistake on x86-64.

[ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
  would never allocate any highmem memory anyway ]
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      dcc6e343
    • Neil Brown's avatar
      md: Fix md grow/size code to correctly find the maximum available space · 75ba82c6
      Neil Brown authored 
      An md array can be asked to change the amount of each device that it is using,
and in particular can be asked to use the maximum available space.  This
currently only works if the first device is not larger than the rest.  As
'size' gets changed and so 'fit' becomes wrong.  So check if a 'fit' is
required early and don't corrupt it.
Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      75ba82c6
    • Zachary Amsden's avatar
      softirq: remove BUG_ONs which can incorrectly trigger · e89da8fc
      Zachary Amsden authored 
      It is possible to have tasklets get scheduled before softirqd has had a chance
to spawn on all CPUs.  This is totally harmless; after success during action
CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
softirqd on the appropriate CPU to process the already pending tasklets.  So
there is no danger of having a missed wakeup for any tasklets that were
already pending.

In particular, i386 is affected by this during startup, and is visible when
using a very large initrd; during the time it takes for the initrd to be
decompressed, a timer IRQ can come in and schedule RCU callbacks.  It is also
possible that resending of a hardware IRQ via a softirq triggers the same bug.

Because of different timing conditions, this shows up in all emulators and
virtual machines tested, including Xen, VMware, Virtual PC, and Qemu.  It is
also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.
Signed-off-by: default avatarZachary Amsden <zach@vmware.com>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      e89da8fc
    • Christophe Saout's avatar
      dm crypt: Fix data corruption with dm-crypt over RAID5 · a26b7719
      Christophe Saout authored 
      Fix corruption issue with dm-crypt on top of software raid5. Cancelled
readahead bio's that report no error, just have BIO_UPTODATE cleared
were reported as successful reads to the higher layers (and leaving
random content in the buffer cache). Already fixed in 2.6.19.
Signed-off-by: default avatarChristophe Saout <christophe@saout.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      a26b7719
    • Christophe Saout's avatar
      Fix SUNRPC wakeup/execute race condition · bbb97831
      Christophe Saout authored 
      The sunrpc scheduler contains a race condition that can let an RPC
task end up being neither running nor on any wait queue. The race takes
place between rpc_make_runnable (called from rpc_wake_up_task) and
__rpc_execute under the following condition:

First __rpc_execute calls tk_action which puts the task on some wait
queue. The task is dequeued by another process before __rpc_execute
continues its execution. While executing rpc_make_runnable exactly after
setting the task `running' bit and before clearing the `queued' bit
__rpc_execute picks up execution, clears `running' and subsequently
both functions fall through, both under the false assumption somebody
else took the job.

Swapping rpc_test_and_set_running with rpc_clear_queued in
rpc_make_runnable fixes that hole. This introduces another possible
race condition that can be handled by checking for `queued' after
setting the `running' bit.

Bug noticed on a 4-way x86_64 system under XEN with an NFSv4 server
on the same physical machine, apparently one of the few ways to hit
this race condition at all.
Signed-off-by: default avatarChristophe Saout <christophe@saout.de>
Acked-by: default avatarTrond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      bbb97831
  15. 14 Dec, 2006 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7