[SRU][Cosmic][Bionic][Xenial][PATCH 0/2] Fixes for LP1800639

Frank Heimes frank.heimes at canonical.com
Thu Nov 1 14:27:55 UTC 2018


BugLink: http://bugs.launchpad.net/bugs/1800639

== SRU Justification ==

Fix socket buffer (skb) leaks for HiperTransport

Description: net/af_iucv: fix skb leaks for HiperTransport
Symptom: Memory leaks and/or double-freed network packets.
Problem: Inbound packets may have any combination of flag bits set in
their iucv header. Current code only handles certain
combinations, and ignores (ie. leaks) all packets with other flags.

On Transmit, current code is inconsistent about whether the error
paths need to free the skb. Depending on which error path is
taken, it may either get freed twice, or leak.
Solution: On receive, drop any skb with an unexpected combination of iucv
Header flags.
On transmit, be consistent in all error paths about free'ing the skb.

== Fix ==

222440996d6daf635bed6cb35041be22ede3e8a0 ("net/af_iucv: drop inbound
packets with invalid flags")
b2f543949acd1ba64313fdad9e672ef47550d773 ("net/af_iucv: fix skb handling on
HiperTransport xmit error")

== Patch ==

commit 222440996d6daf635bed6cb35041be22ede3e8a0
Author: Julian Wiedmann <jwi at linux.ibm.com>
Date:   Wed Sep 5 16:55:10 2018 +0200

    net/af_iucv: drop inbound packets with invalid flags

    Inbound packets may have any combination of flag bits set in their iucv
    header. If we don't know how to handle a specific combination, drop the
    skb instead of leaking it.

    To clarify what error is returned in this case, replace the hard-coded
    0 with the corresponding macro.

    Signed-off-by: Julian Wiedmann <jwi at linux.ibm.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

==

commit b2f543949acd1ba64313fdad9e672ef47550d773
Author: Julian Wiedmann <jwi at linux.ibm.com>
Date:   Wed Sep 5 16:55:11 2018 +0200

    net/af_iucv: fix skb handling on HiperTransport xmit error

    When sending an skb, afiucv_hs_send() bails out on various error
    conditions. But currently the caller has no way of telling whether the
    skb was freed or not - resulting in potentially either
    a) leaked skbs from iucv_send_ctrl(), or
    b) double-free's from iucv_sock_sendmsg().

    As dev_queue_xmit() will always consume the skb (even on error), be
    consistent and also free the skb from all other error paths. This way
    callers no longer need to care about managing the skb.

    Signed-off-by: Julian Wiedmann <jwi at linux.ibm.com>
    Reviewed-by: Ursula Braun <ubraun at linux.ibm.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

== Regression Potential ==

Low, because:
- IUCV functionality is very special to s390x and is only supported in z/VM
environments
  (z/VM hypervisor to guest or guest to guest communications)
- So everything is s390x specific.
- Patch is limited to this single file: /net/iucv/af_iucv.c
- A problem situation was identified by IBM
  that was then fixed, the fix tested and now needs to roled out as
preventive fix.

== Test Case ==

Set IUCV communication on an Ubuntu s390x system that runs as z/VM guest:
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.ludd/ludd_r_afiucv_setup.html
Provoke an error situation.
This is btw. hard to do, because the 'Inter-User Communication Vehicle"
(IUCV) is a virtual z/VM internal
network that does not use any real media.
To check for regressions one can use a shell over an ssh connection using
an IUCV interface
or use an application that utilises AF_IUCV sockets (like ICC).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20181101/ab041b35/attachment.html>


More information about the kernel-team mailing list