diff options
author | Julian Wiedmann <jwi@linux.ibm.com> | 2018-06-29 19:45:53 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-06-30 14:19:48 +0200 |
commit | ce28867fd20c23cd769e78b4d619c4755bf71a1c (patch) | |
tree | d0adb3b90977c45f998bcd940996cc1462a1906b /drivers/s390/net/qeth_l3_main.c | |
parent | s390/qeth: avoid using is_multicast_ether_addr_64bits on (u8 *)[6] (diff) | |
download | linux-ce28867fd20c23cd769e78b4d619c4755bf71a1c.tar.xz linux-ce28867fd20c23cd769e78b4d619c4755bf71a1c.zip |
s390/qeth: don't clobber buffer on async TX completion
If qeth_qdio_output_handler() detects that a transmit requires async
completion, it replaces the pending buffer's metadata object
(qeth_qdio_out_buffer) so that this queue buffer can be re-used while
the data is pending completion.
Later when the CQ indicates async completion of such a metadata object,
qeth_qdio_cq_handler() tries to free any data associated with this
object (since HW has now completed the transfer). By calling
qeth_clear_output_buffer(), it erronously operates on the queue buffer
that _previously_ belonged to this transfer ... but which has been
potentially re-used several times by now.
This results in double-free's of the buffer's data, and failing
transmits as the buffer descriptor is scrubbed in mid-air.
The correct way of handling this situation is to
1. scrub the queue buffer when it is prepared for re-use, and
2. later obtain the data addresses from the async-completion notifier
(ie. the AOB), instead of the queue buffer.
All this only affects qeth devices used for af_iucv HiperTransport.
Fixes: 0da9581ddb0f ("qeth: exploit asynchronous delivery of storage blocks")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/s390/net/qeth_l3_main.c')
0 files changed, 0 insertions, 0 deletions