diff options
author | Dan Williams <dan.j.williams@intel.com> | 2017-09-01 00:41:55 +0200 |
---|---|---|
committer | Dan Williams <dan.j.williams@intel.com> | 2017-09-01 00:41:55 +0200 |
commit | 58738c495e15badd2015e19ff41f1f1ed55200bc (patch) | |
tree | c10882907b7c9a25db21a696af8d0298346a1b90 /lib | |
parent | libnvdimm, nd_blk: remove mmio_flush_range() (diff) | |
download | linux-58738c495e15badd2015e19ff41f1f1ed55200bc.tar.xz linux-58738c495e15badd2015e19ff41f1f1ed55200bc.zip |
libnvdimm: fix integer overflow static analysis warning
Dan reports:
The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for
nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
following static checker warning:
drivers/nvdimm/bus.c:1018 __nd_ioctl()
warn: integer overflows 'buf_len'
From a casual review, this seems like it might be a real bug. On
the first iteration we load some data into in_env[]. On the second
iteration we read a use controlled "in_size" from nd_cmd_in_size().
It can go up to UINT_MAX - 1. A high number means we will fill the
whole in_env[] buffer. But we potentially keep looping and adding
more to in_len so now it can be any value.
It simple enough to change, but it feels weird that we keep looping
even though in_env is totally full. Shouldn't we just return an
error if we don't have space for desc->in_num.
We keep looping because the size of the total input is allowed to be
bigger than the 'envelope' which is a subset of the payload that tells
us how much data to expect. For safety explicitly check that buf_len
does not overflow which is what the checker flagged.
Cc: <stable@vger.kernel.org>
Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions