Searched hist:"0 ac1487c" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/drivers/s390/net/ |
| H A D | qeth_l2_main.c | 0ac1487c Wed Sep 12 08:31:35 CDT 2018 Julian Wiedmann <jwi@linux.ibm.com> s390/qeth: don't dump past end of unknown HW header
For inbound data with an unsupported HW header format, only dump the
actual HW header. We have no idea how much payload follows it, and what
it contains. Worst case, we dump past the end of the Inbound Buffer and
access whatever is located next in memory.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
0ac1487c Wed Sep 12 08:31:35 CDT 2018 Julian Wiedmann <jwi@linux.ibm.com> s390/qeth: don't dump past end of unknown HW header
For inbound data with an unsupported HW header format, only dump the
actual HW header. We have no idea how much payload follows it, and what
it contains. Worst case, we dump past the end of the Inbound Buffer and
access whatever is located next in memory.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | qeth_l3_main.c | 0ac1487c Wed Sep 12 08:31:35 CDT 2018 Julian Wiedmann <jwi@linux.ibm.com> s390/qeth: don't dump past end of unknown HW header
For inbound data with an unsupported HW header format, only dump the
actual HW header. We have no idea how much payload follows it, and what
it contains. Worst case, we dump past the end of the Inbound Buffer and
access whatever is located next in memory.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
0ac1487c Wed Sep 12 08:31:35 CDT 2018 Julian Wiedmann <jwi@linux.ibm.com> s390/qeth: don't dump past end of unknown HW header
For inbound data with an unsupported HW header format, only dump the
actual HW header. We have no idea how much payload follows it, and what
it contains. Worst case, we dump past the end of the Inbound Buffer and
access whatever is located next in memory.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|