netdev - Re: [Oops] unix_dgram_connect locking problem?

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:	Mon, 14 May 2007 03:20:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	deweerdt@...e.fr
Cc:	netdev@...r.kernel.org
Subject: Re: [Oops] unix_dgram_connect locking problem?

From: Frederik Deweerdt <deweerdt@...e.fr>
Date: Fri, 11 May 2007 17:00:14 +0200

> I think that not unix_state_rlock'ing "other" in
> unix_dgram_connect may cause it to become NULL while passing it to
> selinux_socket_unix_may_send. With the following patch applied, I've
> seen no oops so far (1-2 hours as opposed to a few minutes before applying
> the patch). Any thoughts?

Thanks for this report and patch, similar code in UNIX stream connect
has the following comment:

	/* Latch our state.

	   It is tricky place. We need to grab write lock and cannot
	   drop lock on peer. It is dangerous because deadlock is
	   possible. Connect to self case and simultaneous
	   attempt to connect are eliminated by checking socket
	   state. other is TCP_LISTEN, if sk is TCP_LISTEN we
	   check this before attempt to grab lock.

	   Well, and we have to recheck the state after socket locked.
	 */
 ...
	unix_state_wlock_nested(sk);

So I think we need to be careful about deadlocks wrt. holding
both wlock on sk and rlock on other at the same time in
the dgram case too.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html