[REVIEW REQUEST] staging: unisys: review request for visorbus

Dan Carpenter dan.carpenter at oracle.com
Sat Nov 4 06:48:58 UTC 2017


drivers/staging/unisys/visorbus/visorchipset.c
   588  static void *parser_name_get(struct parser_context *ctx)
   589  {
   590          struct visor_controlvm_parameters_header *phdr;
   591  
   592          phdr = &ctx->data;
   593          if (phdr->name_offset + phdr->name_length > ctx->param_bytes)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I am just reviewing quickly.  This looks like a potential integer
overflow if phdr->name_offset is UINT_MAX?

   594                  return NULL;
   595          ctx->curr = (char *)&phdr + phdr->name_offset;
   596          ctx->bytes_remaining = phdr->name_length;
   597          return parser_string_get(ctx->curr, phdr->name_length);
   598  }

drivers/staging/unisys/visorbus/visorchipset.c
  1317  static struct parser_context *parser_init_stream(u64 addr, u32 bytes,
  1318                                                   bool *retry)
  1319  {
  1320          int allocbytes;
  1321          struct parser_context *ctx;
  1322          void *mapping;
  1323  
  1324          *retry = false;
  1325          /* alloc an extra byte to ensure payload is \0 terminated */
  1326          allocbytes = bytes + 1 + (sizeof(struct parser_context) -
  1327                       sizeof(struct visor_controlvm_parameters_header));
  1328          if ((chipset_dev->controlvm_payload_bytes_buffered + bytes) >

Same question.  Can this or the allocbytes calculation have an integer
overflow?

  1329               MAX_CONTROLVM_PAYLOAD_BYTES) {
  1330                  *retry = true;
  1331                  return NULL;
  1332          }
  1333          ctx = kzalloc(allocbytes, GFP_KERNEL);
  1334          if (!ctx) {
  1335                  *retry = true;
  1336                  return NULL;
  1337          }
  1338          ctx->allocbytes = allocbytes;
  1339          ctx->param_bytes = bytes;

Otherwise the code looks pretty clean to me.

regards,
dan carpenter



More information about the devel mailing list