All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Nyberg <alexn@dsv.su.se>
To: Jani Jaakkola <jjaakkol@cs.Helsinki.FI>
Cc: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix reproducible SMP crash in security/keys/key.c
Date: Wed, 13 Apr 2005 10:55:15 +0200	[thread overview]
Message-ID: <1113382515.917.5.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0504122129510.3075@x40-4.cs.helsinki.fi>

tis 2005-04-12 klockan 21:58 +0300 skrev Jani Jaakkola:
> SMP race handling is broken in key_user_lookup() in security/keys/key.c
> (if CONFIG_KEYS is set to 'y'). This came up on our Samba servers, but is
> not restricted to samba, though samba is probably the only software which
> is likely to trigger this repeatedly (and it did happen allready four 
> times here in University of Helsinki, CS department).
> 
> However, it only takes two setreuid() calls at the same instant, so this
> may be responsible for some other mysterious random crashes.
> 
> This is the same bug which was previously raported to LKML here (found by 
> google):
> http://www.ussg.iu.edu/hypermail/linux/kernel/0502.2/0521.html
> 
> Here is a small test program, which can be used to trigger the bug and 
> crash the machine where it is run. It might take a few seconds:
> 
> #include<unistd.h>
> #include<stdio.h>
> int main() {
>         int i;
>         fork();
>         while(1) {
>                 for(i=0;i<60000;i++) { setreuid(i,0); } 
>                 putchar('.'); fflush(stdout);
>         };
> }
> 
> The (rather obvious) problem is that key_user_lookup() does not properly 
> re-initialize the user lookup if there was a race.
> 
> This patch applies to vanilla 2.6.11.7 and latest fedora kernel
> 2.6.11-1.14_FC3. When applied, the test program runs just fine (and does
> nothing useful).

A fix went into mainline for this two months ago (post 2.6.11), but I
probably should have sent it into -stable aswell.

For your own sake always use the latest kernel when looking at
problems/fixes, things move fast around here :)


  reply	other threads:[~2005-04-13  8:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 18:58 [PATCH] Fix reproducible SMP crash in security/keys/key.c Jani Jaakkola
2005-04-13  8:55 ` Alexander Nyberg [this message]
2005-04-13  9:02 ` Andrew Morton
2005-04-13 16:18   ` [stable] " Chris Wright
2005-04-13  9:37 ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1113382515.917.5.camel@localhost.localdomain \
    --to=alexn@dsv.su.se \
    --cc=dhowells@redhat.com \
    --cc=jjaakkol@cs.Helsinki.FI \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.