• M
    sctp: fix the handling of ICMP Frag Needed for too small MTUs · b6c5734d
    Marcelo Ricardo Leitner 提交于
    syzbot reported a hang involving SCTP, on which it kept flooding dmesg
    with the message:
    [  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
    low, using default minimum of 512
    
    That happened because whenever SCTP hits an ICMP Frag Needed, it tries
    to adjust to the new MTU and triggers an immediate retransmission. But
    it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
    allowed (512) would not cause the PMTU to change, and issued the
    retransmission anyway (thus leading to another ICMP Frag Needed, and so
    on).
    
    As IPv4 (ip_rt_min_pmtu=556) and IPv6 (IPV6_MIN_MTU=1280) minimum MTU
    are higher than that, sctp_transport_update_pmtu() is changed to
    re-fetch the PMTU that got set after our request, and with that, detect
    if there was an actual change or not.
    
    The fix, thus, skips the immediate retransmission if the received ICMP
    resulted in no change, in the hope that SCTP will select another path.
    
    Note: The value being used for the minimum MTU (512,
    SCTP_DEFAULT_MINSEGMENT) is not right and instead it should be (576,
    SCTP_MIN_PMTU), but such change belongs to another patch.
    
    Changes from v1:
    - do not disable PMTU discovery, in the light of commit
    06ad3919 ("[SCTP] Don't disable PMTU discovery when mtu is small")
    and as suggested by Xin Long.
    - changed the way to break the rtx loop by detecting if the icmp
      resulted in a change or not
    Changes from v2:
    none
    
    See-also: https://lkml.org/lkml/2017/12/22/811Reported-by: Nsyzbot <syzkaller@googlegroups.com>
    Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    b6c5734d
transport.c 21.1 KB