All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luís Henriques" <luis.henriques@canonical.com>
To: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH < v3.10] ipc/msg: fix race around refcount
Date: Mon, 31 Mar 2014 10:09:08 +0100	[thread overview]
Message-ID: <20140331090908.GC5042@hercules> (raw)
In-Reply-To: <20140326101218.11221.74072.stgit@buzz>

On Wed, Mar 26, 2014 at 02:12:19PM +0400, Konstantin Khlebnikov wrote:
> In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int.
> There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under
> msq->q_perm->lock and RCU, while freequeue() calls it while it holds only
> 'rw_mutex', so there is no sinchronization between them. Two function
> decrements '2' non-atomically, they both can get '0' as result.
> 
> do_msgsnd()					freequeue()
> 
> msq = msg_lock_check(ns, msqid);
> ...
> ipc_rcu_getref(msq);
> msg_unlock(msq);
> schedule();
> 						(caller locks spinlock)
> 						expunge_all(msq, -EIDRM);
> 						ss_wakeup(&msq->q_senders, 1);
> 						msg_rmid(ns, msq);
> 						msg_unlock(msq);
> ipc_lock_by_ptr(&msq->q_perm);
> ipc_rcu_putref(msq);				ipc_rcu_putref(msq);
> < both may get get --(...)->refcount == 0 >
> 
> This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue.
> ( RCU protects memory for spin_unlock() )
> 
> Similar bugs might be in other users of ipc_rcu_putref().
> 
> In the mainline this has been fixed in v3.10 indirectly in commmit
> 6062a8dc0517bce23e3c2f7d2fea5e22411269a3
> ("ipc,sem: fine grained locking for semtimedop") by Rik van Riel.
> That commit optimized locking and converted refcount into atomic.
> 
> I'm not sure that anybody should care about this bug: it's very-very unlikely
> and no longer exists in actual mainline. I've found this just by looking into
> the code, probably this never happens in real life.
> 
> Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>

Thank you, I'm queuing this for the 3.5 kernel.

Cheers,
--
Luís

> ---
>  ipc/msg.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/ipc/msg.c b/ipc/msg.c
> index 7385de2..25f1a61 100644
> --- a/ipc/msg.c
> +++ b/ipc/msg.c
> @@ -296,7 +296,9 @@ static void freeque(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp)
>  	}
>  	atomic_sub(msq->q_cbytes, &ns->msg_bytes);
>  	security_msg_queue_free(msq);
> +	ipc_lock_by_ptr(&msq->q_perm);
>  	ipc_rcu_putref(msq);
> +	ipc_unlock(&msq->q_perm);
>  }
>  
>  /*
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Luís Henriques" <luis.henriques@canonical.com>
To: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH < v3.10] ipc/msg: fix race around refcount
Date: Mon, 31 Mar 2014 10:09:08 +0100	[thread overview]
Message-ID: <20140331090908.GC5042@hercules> (raw)
In-Reply-To: <20140326101218.11221.74072.stgit@buzz>

On Wed, Mar 26, 2014 at 02:12:19PM +0400, Konstantin Khlebnikov wrote:
> In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int.
> There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under
> msq->q_perm->lock and RCU, while freequeue() calls it while it holds only
> 'rw_mutex', so there is no sinchronization between them. Two function
> decrements '2' non-atomically, they both can get '0' as result.
> 
> do_msgsnd()					freequeue()
> 
> msq = msg_lock_check(ns, msqid);
> ...
> ipc_rcu_getref(msq);
> msg_unlock(msq);
> schedule();
> 						(caller locks spinlock)
> 						expunge_all(msq, -EIDRM);
> 						ss_wakeup(&msq->q_senders, 1);
> 						msg_rmid(ns, msq);
> 						msg_unlock(msq);
> ipc_lock_by_ptr(&msq->q_perm);
> ipc_rcu_putref(msq);				ipc_rcu_putref(msq);
> < both may get get --(...)->refcount == 0 >
> 
> This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue.
> ( RCU protects memory for spin_unlock() )
> 
> Similar bugs might be in other users of ipc_rcu_putref().
> 
> In the mainline this has been fixed in v3.10 indirectly in commmit
> 6062a8dc0517bce23e3c2f7d2fea5e22411269a3
> ("ipc,sem: fine grained locking for semtimedop") by Rik van Riel.
> That commit optimized locking and converted refcount into atomic.
> 
> I'm not sure that anybody should care about this bug: it's very-very unlikely
> and no longer exists in actual mainline. I've found this just by looking into
> the code, probably this never happens in real life.
> 
> Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>

Thank you, I'm queuing this for the 3.5 kernel.

Cheers,
--
Lu�s

> ---
>  ipc/msg.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/ipc/msg.c b/ipc/msg.c
> index 7385de2..25f1a61 100644
> --- a/ipc/msg.c
> +++ b/ipc/msg.c
> @@ -296,7 +296,9 @@ static void freeque(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp)
>  	}
>  	atomic_sub(msq->q_cbytes, &ns->msg_bytes);
>  	security_msg_queue_free(msq);
> +	ipc_lock_by_ptr(&msq->q_perm);
>  	ipc_rcu_putref(msq);
> +	ipc_unlock(&msq->q_perm);
>  }
>  
>  /*
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-03-31  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 10:12 [PATCH < v3.10] ipc/msg: fix race around refcount Konstantin Khlebnikov
2014-03-31  9:09 ` Luís Henriques [this message]
2014-03-31  9:09   ` Luís Henriques
2014-04-06 13:00 ` Ben Hutchings

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=20140331090908.GC5042@hercules \
    --to=luis.henriques@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=k.khlebnikov@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@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.