summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/nvmem
diff options
context:
space:
mode:
authorDan Carpenter <dan.carpenter@oracle.com>2017-09-30 14:27:41 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-10-04 10:30:53 +0200
commitbd14798650cd2a2befd7d96bbc466c2317a582db (patch)
tree808271cac5e16c798a3705f34d5787dd807691b2 /Documentation/devicetree/bindings/nvmem
parentebc4768ac4971eab4b570e733e47ac9dfd0e4175 (diff)
vme: Fix integer overflow checking in vme_check_window()
The controversial part of this patch is that I've changed it so we now prevent integer overflows for VME_USER types and before we didn't. I view it as kernel-hardening. I looked at a couple places that used VME_USER types and they seemed pretty suspicious so I'm pretty sure preventing overflows here is a good idea. The most common problem which this function is for cases like VME_A16 where we don't put an upper bound on "size" so you could have "size" set to U64_MAX and a valid vme_base would overflow the "vme_base + size" into the valid range as well. In the VME_A64 case, the integer overflow checking doesn't work because "U64_MAX + 1" has an integer overflow and it's just a complicated way of saying zero. That VME_A64 case is sort of interesting as well because there is a VME_A64_MAX define which is set to "U64_MAX + 1". The compiler will never let anyone use it since it can't be stored in a u64 variable... With my patch it's now limited to just U64_MAX. Anyway, I put one integer overflow check at the start of the function and deleted all existing checks. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/devicetree/bindings/nvmem')
0 files changed, 0 insertions, 0 deletions