public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Netes <alexne-smomgflXvOZWk0Htik3J/w@public.gmane.org>
To: Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH/opensm] Decode the SAPKeyTableRecord block number properly, and don't segv
Date: Fri, 25 Feb 2011 13:25:15 +0200	[thread overview]
Message-ID: <20110225112514.GC8537@calypso.voltaire.com> (raw)
In-Reply-To: <AANLkTinm5Uh-9h+WMh6O8dLsPr8wpdt0BJmOu3+Dt8vj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 14:01 Wed 23 Feb     , Hal Rosenstock wrote:
> On Wed, Feb 23, 2011 at 12:20 PM, Alex Netes <alexne-smomgflXvOZWk0Htik3J/w@public.gmane.org> wrote:
> > Hi Jason,
> >
> > On 15:12 Fri 11 Feb     , Jason Gunthorpe wrote:
> >> * Properly byteswap block_num before using it
> >> * Properly check bounds of the block number before de-referencing it.
> >>
> >> This fixes a remotely triggered null pointer dereference.
> >> ---
> >>  opensm/include/iba/ib_types.h      |    2 +-
> >>  opensm/opensm/osm_sa_pkey_record.c |   16 ++++++++++++----
> >>  2 files changed, 13 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/opensm/include/iba/ib_types.h b/opensm/include/iba/ib_types.h
> >> index e1bc102..24f5662 100644
> >> --- a/opensm/include/iba/ib_types.h
> >> +++ b/opensm/include/iba/ib_types.h
> >> @@ -6724,7 +6724,7 @@ typedef struct _ib_pkey_table {
> >>  #include <complib/cl_packon.h>
> >>  typedef struct _ib_pkey_table_record {
> >>       ib_net16_t lid;         // for CA: lid of port, for switch lid of port 0
> >> -     uint16_t block_num;
> >> +     ib_net16_t block_num;
> >>       uint8_t port_num;       // for switch: port number, for CA: reserved
> >>       uint8_t reserved1;
> >>       uint16_t reserved2;
> >
> > I guess reserved2 could also be changed to ib_net16_t, right?
> >
> >> diff --git a/opensm/opensm/osm_sa_pkey_record.c b/opensm/opensm/osm_sa_pkey_record.c
> >> index e4930d0..cf50430 100644
> >> --- a/opensm/opensm/osm_sa_pkey_record.c
> >> +++ b/opensm/opensm/osm_sa_pkey_record.c
> >> @@ -71,6 +71,7 @@ static void sa_pkey_create(IN osm_sa_t * sa, IN osm_physp_t * p_physp,
> >>       osm_pkey_item_t *p_rec_item;
> >>       uint16_t lid;
> >>       ib_api_status_t status = IB_SUCCESS;
> >> +     ib_pkey_table_t *tbl;
> >>
> >>       OSM_LOG_ENTER(sa->p_log);
> >>
> >> @@ -98,8 +99,15 @@ static void sa_pkey_create(IN osm_sa_t * sa, IN osm_physp_t * p_physp,
> >>       p_rec_item->rec.lid = lid;
> >>       p_rec_item->rec.block_num = block;
> >>       p_rec_item->rec.port_num = osm_physp_get_port_num(p_physp);
> >> -     p_rec_item->rec.pkey_tbl =
> >> -         *(osm_pkey_tbl_block_get(osm_physp_get_pkey_tbl(p_physp), block));
> >> +     /* FIXME: There are ninf.PartitionCap or swinf.PartitionEnforcementCap
> >> +        pkey entries so everything in that range is a valid block number
> >> +        even if opensm is not using it. Return 0. However things outside
> >> +        that range should return no entries.. Not sure how to figure that
> >> +        here? The range of pkey_tbl can be less than the cap, so
> >> +        this falsely triggers. */
> >> +     tbl = osm_pkey_tbl_block_get(osm_physp_get_pkey_tbl(p_physp), block);
> >> +     if (tbl)
> >> +             p_rec_item->rec.pkey_tbl = *tbl;
> >>
> >>       cl_qlist_insert_tail(p_ctxt->p_list, &p_rec_item->list_item);
> >
> > What is the expected behaviour when IB PKey table block is empty?
> > rec.pkey_tbl might be uninitialized here.
> > Shouldn't SubnAdmGetResp contain ERR_NO_RECORDS in such case?
> 
> It depends on the method used in the SA query. GetTable never returns
> ERR_NO_RECORDS whereas a Get can.
> 

In case when IB PKey table block is empty, p_rec_item->rec.pkey_tbl would be uninitialized.

> -- Hal
> 
> >>
> >> @@ -269,14 +277,14 @@ void osm_pkey_rec_rcv_process(IN void *ctx, IN void *data)
> >>       context.p_list = &rec_list;
> >>       context.comp_mask = p_rcvd_mad->comp_mask;
> >>       context.sa = sa;
> >> -     context.block_num = p_rcvd_rec->block_num;
> >> +     context.block_num = cl_ntoh16(p_rcvd_rec->block_num);
> >>       context.p_req_physp = p_req_physp;
> >>
> >>       OSM_LOG(sa->p_log, OSM_LOG_DEBUG,
> >>               "Got Query Lid:%u(%02X), Block:0x%02X(%02X), Port:0x%02X(%02X)\n",
> >>               cl_ntoh16(p_rcvd_rec->lid),
> >>               (comp_mask & IB_PKEY_COMPMASK_LID) != 0, p_rcvd_rec->port_num,
> >> -             (comp_mask & IB_PKEY_COMPMASK_PORT) != 0, p_rcvd_rec->block_num,
> >> +             (comp_mask & IB_PKEY_COMPMASK_PORT) != 0, context.block_num,
> >>               (comp_mask & IB_PKEY_COMPMASK_BLOCK) != 0);
> >>
> >>       cl_plock_acquire(sa->p_lock);
> >> --
> >> 1.7.1
> >>
> >
> > Alex
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2011-02-25 11:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11 22:12 [PATCH/opensm] Decode the SAPKeyTableRecord block number properly, and don't segv Jason Gunthorpe
     [not found] ` <20110211221206.GA8532-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-02-23 17:20   ` Alex Netes
     [not found]     ` <20110223172019.GA8537-iQai9MGU/dyyaiaB+Ve85laTQe2KTcn/@public.gmane.org>
2011-02-23 18:13       ` Jason Gunthorpe
2011-02-23 19:01       ` Hal Rosenstock
     [not found]         ` <AANLkTinm5Uh-9h+WMh6O8dLsPr8wpdt0BJmOu3+Dt8vj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-02-23 20:21           ` Hal Rosenstock
2011-02-25 11:25           ` Alex Netes [this message]
     [not found]             ` <20110225112514.GC8537-iQai9MGU/dyyaiaB+Ve85laTQe2KTcn/@public.gmane.org>
2011-02-25 19:35               ` Jason Gunthorpe
     [not found]                 ` <20110225193509.GA9157-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-02-25 22:02                   ` Alex Netes
2011-02-25 22:12   ` Alex Netes

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=20110225112514.GC8537@calypso.voltaire.com \
    --to=alexne-smomgflxvozwk0htik3j/w@public.gmane.org \
    --cc=hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox