lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Jul 2007 00:43:27 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Jeremy Katz <jeremy.katz@...driver.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...e.hu>,
	Stable Team <stable@...nel.org>
Subject: Re: [PATCH] posix-timer: fix deletion race

On 07/24, Jeremy Katz wrote:
>
> On Tue, 24 Jul 2007, Oleg Nesterov wrote:
> 
> >Interesting. Could you show the patch? Where does sys_timer_create() set
> >counter == 1?
> 
> --- kernel/posix-timers.c.old      2007-07-24 11:21:29.000000000 -0700
> +++ kernel/posix-timers.c       2007-07-20 15:49:51.000000000 -0700
> @@ -409,13 +409,17 @@ static struct k_itimer * alloc_posix_tim
>  #define IT_ID_NOT_SET  0
>  static void release_posix_timer(struct k_itimer *tmr, int it_id_set)
>  {
> +       atomic_inc(&tmr->freecount);
> @@ -443,6 +447,7 @@ sys_timer_create(const clockid_t which_c
>         new_timer = alloc_posix_timer();
>         if (unlikely(!new_timer))
>                 return -EAGAIN;
> +       atomic_set(&new_timer->freecount, 0);
> 
> --- include/linux/posix-timers.h.old  2007-07-24 11:32:36.000000000 -0700
> +++ include/linux/posix-timers.h      2007-07-20 15:15:44.000000000 -0700
> @@ -62,6 +62,7 @@ struct k_itimer {
>                         unsigned long expires;
>                 } mmtimer;
>         } it;
> +       atomic_t freecount;
>  };
> 
>  struct k_clock {
> 
> 
> Examination was done through a kgdb session when it caught the bug. 
> freecount always had the expected value, 1 during a delete operation, 
> and 0 otherwise.

OK, thanks.

> >>>Could you try the patch below? Perhaps we have some wierd problem with
> >>>->sigq corruption.
> >>
> >>Tried, with apparent effect.
> >
> >You mean, "null pointer dereference" in release_posix_timer() ? Or it was
> >BUG_ON(timr && !timr->sigq) in lock_timer() ?
> 
> Sorry.  That should have been "without apparent effect".

Sorry. I confused completely.

So. You mean that even with that patch you _still_ see the BUG_ON(!SIGQUEUE_PREALLOC)
in sigqueue_free() ?

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ