On Thu, Feb 15, 2018 at 09:26:04AM -0700, Jason Gunthorpe wrote: > On Thu, Feb 15, 2018 at 03:56:28PM +0200, Leon Romanovsky wrote: > > On Wed, Feb 14, 2018 at 04:47:14PM -0700, Jason Gunthorpe wrote: > > > On Wed, Feb 14, 2018 at 02:38:38PM +0200, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > > > > > The check based on index is not sufficient because > > > > > > > > IB_USER_VERBS_EX_CMD_CREATE_CQ = IB_USER_VERBS_CMD_CREATE_CQ > > > > > > > > and IB_USER_VERBS_CMD_CREATE_CQ <= IB_USER_VERBS_CMD_OPEN_QP, > > > > so if we execute IB_USER_VERBS_EX_CMD_CREATE_CQ this code checks > > > > ib_dev->uverbs_cmd_mask not ib_dev->uverbs_ex_cmd_mask. > > > > > > > > Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > drivers/infiniband/core/uverbs_main.c | 18 ++++++------------ > > > > 1 file changed, 6 insertions(+), 12 deletions(-) > > > > > > This seems like an RC fix to me, since we are not properly validating > > > input commands... ?? > > > > I don't think so, it looks harmless to me because all vendors except mlx4/mlx5 > > have zero in uverbs_ex_cmd_mask and mlx4 have all commands implemented. > > The issue is we check uverbs_cmd_mask when we should check > uverbs_ex_cmd_mask, so drivers with a 0 in uverbs_ex_cmd_mask will > still pass this check. > > and your later patch checks for null, so what happens if, say, rxe > calls an ex command? kernel oops? So actually, my latest patch (addition of NULL checks) should go to the -rc and not this one. I still prefer to leave this patch in this series (-next) and avoid writing completely thrown away code for -rc, which will create only merge conflicts between rdma-rc and rdma-next without any visible benefits. I'll reshuffle this series and resubmit. Thanks > > Jason
Attachment:
signature.asc
Description: PGP signature
