summaryrefslogtreecommitdiff
path: root/block
diff options
context:
space:
mode:
authorDan Williams <dan.j.williams@intel.com>2018-02-24 01:05:38 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-02-28 12:18:33 +0300
commit29c969c3031b20595f6c3a0d16348cf6d11d8a13 (patch)
tree156766ac918fd6034ff3664bc89611d14906c220 /block
parentf06c2c659ccad2c5da074311a6980cd888ea2779 (diff)
downloadlinux-29c969c3031b20595f6c3a0d16348cf6d11d8a13.tar.xz
libnvdimm: fix integer overflow static analysis warning
commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions