linux-kernel - Re: [PATCH] CRED: Further fix execve error handling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Aug 2008 17:33:20 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Alexander Beregalov" <a.beregalov@...il.com>
Cc:	"David Howells" <dhowells@...hat.com>, jmorris@...ei.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] CRED: Further fix execve error handling

On Wed, 20 Aug 2008 18:21:59 +0400
"Alexander Beregalov" <a.beregalov@...il.com> wrote:

> 2008/8/20 David Howells <dhowells@...hat.com>:
> > Further fix [compat_]do_execve() error handling.  free_bprm() will release the
> > cred_exec_mutex, but only if bprm->cred is not NULL.
> >
> > Signed-off-by: David Howells <dhowells@...hat.com>
> 
> David, I applied this patch and got the following.
> Is it a different problem?
> I think it is. If yes I will create another topic.
> 
> [   91.266507] [ INFO: possible recursive locking detected ]
> [   91.266862] 2.6.27-rc3-next-20080820-dirty #3

Looks like a false trip of the lock debugging code. I've seen the same
and having dumped the values in tty_do_resize plus the entry/exit paths
it seems to be bogus.

> [   91.267170] ---------------------------------------------
> [   91.267522] sshd/1455 is trying to acquire lock:
> [   91.267840]  (&tty->termios_mutex){--..}, at: [<00000000005b8ca0>]
> tty_do_resize+0x44/0x128
> [   91.268405]
> [   91.268411] but task is already holding lock:
> [   91.268885]  (&tty->termios_mutex){--..}, at: [<00000000005b8c74>]
> tty_do_resize+0x18/0x128

Note that the lock is only acquired in one place in this code and that
the second lock is only take if the two locks differ. Also the second
lock take is not &tty->termios_mutex at all but real_tty.

So I'd say either broken compiler or broken lock debug tools but hey I
could be wrong ;)

Alan
--
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/