| Message ID | 1303759770-15708-1-git-send-email-brad.figg@canonical.com |
|---|---|
| State | New |
| Headers | show |
On 04/25/2011 01:29 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> > > (cherry-picked 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 64e0903..1d9616b 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2989,6 +2989,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_irq(&cm.lock); > > 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:29 -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> > > (cherry-picked 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 64e0903..1d9616b 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2989,6 +2989,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_irq(&cm.lock); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; > -- > 1.7.0.4 > >
On 04/25/2011 12:29 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> > > (cherry-picked from commit 29963437a48475036353b95ab142bf199adb909e) > Signed-off-by: Brad Figg <brad.figg@canonical.com> Acked-by: John Johansen <john.johansen@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 64e0903..1d9616b 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2989,6 +2989,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_irq(&cm.lock); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler;
On 04/25/2011 01:29 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> > > (cherry-picked 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 64e0903..1d9616b 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -2989,6 +2989,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_irq(&cm.lock); > > cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; I'm a bit curious how you got these 2 patches to apply 'cause they were released with 2.6.35-29.51. Did you start with master instead of master-next ? rtg
On 04/25/2011 05:53 PM, Tim Gardner wrote: > On 04/25/2011 01:29 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> >> >> (cherry-picked 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 64e0903..1d9616b 100644 >> --- a/drivers/infiniband/core/cm.c >> +++ b/drivers/infiniband/core/cm.c >> @@ -2989,6 +2989,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_irq(&cm.lock); >> >> cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler; > > I'm a bit curious how you got these 2 patches to apply 'cause they were released with 2.6.35-29.51. Did you start with master instead of master-next ? > > rtg That's a really good question. I patched an old local repo. I got distracted working on these and thought I'd updated my repo but had not. Thanks for catching this and sorry to waste everyone's time. Brad
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c index 64e0903..1d9616b 100644 --- a/drivers/infiniband/core/cm.c +++ b/drivers/infiniband/core/cm.c @@ -2989,6 +2989,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_irq(&cm.lock); cm_id_priv->id.cm_handler = cur_cm_id_priv->id.cm_handler;