| Message ID | 1303759722-15174-1-git-send-email-brad.figg@canonical.com |
|---|---|
| State | New |
| Headers | show |
On 04/25/2011 01:28 PM, Brad Figg wrote: > From: Sean Hefty<sean.hefty@intel.com> > > CVE-2011-0695 > > BugLink: http://bugs.launchpad.net/bugs/770369 > > When processing a SIDR REQ, the ib_cm allocates a new cm_id. The > refcount of the cm_id is initialized to 1. However, cm_process_work > will decrement the refcount after invoking all callbacks. The result > is that the cm_id will end up with refcount set to 0 by the end of the > sidr req handler. > > If a user tries to destroy the cm_id, the destruction will proceed, > under the incorrect assumption that no other threads are referencing > the cm_id. This can lead to a crash when the cm callback thread tries > to access the cm_id. > > This problem was noticed as part of a larger investigation with kernel > crashes in the rdma_cm when running on a real time OS. > > Signed-off-by: Sean Hefty<sean.hefty@intel.com> > Acked-by: Doug Ledford<dledford@redhat.com> > Cc:<stable@kernel.org> > Signed-off-by: Roland Dreier<roland@purestorage.com> > > (backported from commit 29963437a48475036353b95ab142bf199adb909e) > Signed-off-by: Brad Figg<brad.figg@canonical.com> > --- > drivers/infiniband/core/cm.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c > index 02110e0..c777dbd 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2648,6 +2648,7 @@ static int cm_sidr_req_handler(struct cm_work *work) > goto out; /* No match. */ > } > atomic_inc(&cur_cm_id_priv->refcount); > + atomic_inc(&cm_id_priv->refcount); > spin_unlock_irqrestore(&cm.lock, flags); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; Acked-by: Tim Gardner <tim.gardner@canonical.com>
On Mon, 2011-04-25 at 12:28 -0700, Brad Figg wrote: > From: Sean Hefty <sean.hefty@intel.com> > > CVE-2011-0695 > > BugLink: http://bugs.launchpad.net/bugs/770369 > > When processing a SIDR REQ, the ib_cm allocates a new cm_id. The > refcount of the cm_id is initialized to 1. However, cm_process_work > will decrement the refcount after invoking all callbacks. The result > is that the cm_id will end up with refcount set to 0 by the end of the > sidr req handler. > > If a user tries to destroy the cm_id, the destruction will proceed, > under the incorrect assumption that no other threads are referencing > the cm_id. This can lead to a crash when the cm callback thread tries > to access the cm_id. > > This problem was noticed as part of a larger investigation with kernel > crashes in the rdma_cm when running on a real time OS. > > Signed-off-by: Sean Hefty <sean.hefty@intel.com> > Acked-by: Doug Ledford <dledford@redhat.com> > Cc: <stable@kernel.org> > Signed-off-by: Roland Dreier <roland@purestorage.com> > > (backported from commit 29963437a48475036353b95ab142bf199adb909e) > Signed-off-by: Brad Figg <brad.figg@canonical.com> Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> > --- > drivers/infiniband/core/cm.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c > index 02110e0..c777dbd 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2648,6 +2648,7 @@ static int cm_sidr_req_handler(struct cm_work *work) > goto out; /* No match. */ > } > atomic_inc(&cur_cm_id_priv->refcount); > + atomic_inc(&cm_id_priv->refcount); > spin_unlock_irqrestore(&cm.lock, flags); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; > -- > 1.7.0.4 > >
On 04/25/2011 01:28 PM, Brad Figg wrote: > From: Sean Hefty<sean.hefty@intel.com> > > CVE-2011-0695 > > BugLink: http://bugs.launchpad.net/bugs/770369 > > When processing a SIDR REQ, the ib_cm allocates a new cm_id. The > refcount of the cm_id is initialized to 1. However, cm_process_work > will decrement the refcount after invoking all callbacks. The result > is that the cm_id will end up with refcount set to 0 by the end of the > sidr req handler. > > If a user tries to destroy the cm_id, the destruction will proceed, > under the incorrect assumption that no other threads are referencing > the cm_id. This can lead to a crash when the cm callback thread tries > to access the cm_id. > > This problem was noticed as part of a larger investigation with kernel > crashes in the rdma_cm when running on a real time OS. > > Signed-off-by: Sean Hefty<sean.hefty@intel.com> > Acked-by: Doug Ledford<dledford@redhat.com> > Cc:<stable@kernel.org> > Signed-off-by: Roland Dreier<roland@purestorage.com> > > (backported from commit 29963437a48475036353b95ab142bf199adb909e) > Signed-off-by: Brad Figg<brad.figg@canonical.com> > --- > drivers/infiniband/core/cm.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c > index 02110e0..c777dbd 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2648,6 +2648,7 @@ static int cm_sidr_req_handler(struct cm_work *work) > goto out; /* No match. */ > } > atomic_inc(&cur_cm_id_priv->refcount); > + atomic_inc(&cm_id_priv->refcount); > spin_unlock_irqrestore(&cm.lock, flags); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; applied
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index 02110e0..c777dbd 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -2648,6 +2648,7 @@ static int cm_sidr_req_handler(struct cm_work *work) goto out; /* No match. */ } atomic_inc(&cur_cm_id_priv->refcount); + atomic_inc(&cm_id_priv->refcount); spin_unlock_irqrestore(&cm.lock, flags); cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler;