diff options
author | Ian Munsie <imunsie@au1.ibm.com> | 2016-06-29 12:16:25 (GMT) |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2016-07-08 12:10:42 (GMT) |
commit | 49e9c99f47fc43abc9598f9fcf5ba3336d0c09a6 (patch) | |
tree | ab4bd2570417d66ae097aab40fbd6393a8dc09be /usr | |
parent | bdd910017c6a4d0a53e4e69d1bf92d576e305a47 (diff) | |
download | linux-49e9c99f47fc43abc9598f9fcf5ba3336d0c09a6.tar.xz |
cxl: Fix allowing bogus AFU descriptors with 0 maximum processes
If the AFU descriptor of an AFU directed AFU indicates that it supports
0 maximum processes, we will accept that value and attempt to use it.
The SPA will still be allocated (with 2 pages due to another minor bug
and room for 958 processes), and when a context is allocated we will
pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will
treat that as meaning no maximum and will allocate a context number and
we return a valid context.
Conceivably, this could lead to a buffer overflow of the SPA if more
than 958 contexts were allocated, however this is mitigated by the fact
that there are no known AFUs in the wild with a bogus AFU descriptor
like this, and that only the root user is allowed to flash an AFU image
to a card.
Add a check when validating the AFU descriptor to reject any with 0
maximum processes.
We do still allow a dedicated process only AFU to indicate that it
supports 0 contexts even though that is forbidden in the architecture,
as in that case we ignore the value and use 1 instead. This is just on
the off-chance that such a dedicated process AFU may exist (not that I
am aware of any), since their developers are less likely to have cared
about this value at all.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions