diff options
author | Dan Carpenter <dan.carpenter@oracle.com> | 2017-09-30 14:27:41 +0300 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2017-10-04 10:30:53 +0200 |
commit | bd14798650cd2a2befd7d96bbc466c2317a582db (patch) | |
tree | 808271cac5e16c798a3705f34d5787dd807691b2 /drivers/zorro | |
parent | ebc4768ac4971eab4b570e733e47ac9dfd0e4175 (diff) | |
download | talos-op-linux-bd14798650cd2a2befd7d96bbc466c2317a582db.tar.gz talos-op-linux-bd14798650cd2a2befd7d96bbc466c2317a582db.zip |
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 'drivers/zorro')
0 files changed, 0 insertions, 0 deletions