[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432288230.3364.23.camel@redhat.com>
Date: Fri, 22 May 2015 11:50:30 +0200
From: Hannes Frederic Sowa <hannes@...hat.com>
To: Mark Salyzyn <salyzyn@...roid.com>
Cc: linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Al Viro <viro@...iv.linux.org.uk>,
David Howells <dhowells@...hat.com>,
Ying Xue <ying.xue@...driver.com>,
Christoph Hellwig <hch@....de>, netdev@...r.kernel.org
Subject: Re: net/unix: sk_socket can disappear when state is unlocked
On Do, 2015-05-21 at 09:25 -0700, Mark Salyzyn wrote:
> got a rare NULL pointer dereference in clear_bit
>
> Signed-off-by: Mark Salyzyn <salyzyn@...roid.com>
> ---
> net/unix/af_unix.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 5266ea7..37a8925 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1880,6 +1880,11 @@ static long unix_stream_data_wait(struct sock *sk, long timeo,
> unix_state_unlock(sk);
> timeo = freezable_schedule_timeout(timeo);
> unix_state_lock(sk);
> +
> + /* sk_socket may have been killed while unlocked */
> + if (!sk->sk_socket)
> + break;
> +
> clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
> }
>
Canonical way is to test for sock_flag(sk, SOCK_DEAD). Also it does not
seem like we are returning an error to user space but are still looping
to try to dequeue skbs from sk_receive_queue, which is concurrently
emptied by unix_release (maybe, without holding unix_state_lock).
Bye,
Hannes
--
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
Powered by blists - more mailing lists