---
- branch: netbsd-8
  date: Fri Mar 30 11:10:14 UTC 2018
  files:
  - new: 1.11.8.1
    old: '1.11'
    path: src/sys/netinet/ip_reass.c
    pathrev: src/sys/netinet/ip_reass.c@1.11.8.1
    type: modified
  id: 20180330T111014Z.503e1f50ba8c675662e7bd118d5a7d16dc04bc4f
  log: "Pull up following revision(s) (requested by maxv in ticket #668):\n\tsys/netinet/ip_reass.c:
    revision 1.12\n\nAdd one more check in ip_reass_packet(): make sure that the end
    of each\nfragment does not exceed IP_MAXPACKET.\n\nIn ip_reass(), we only check
    the final length of the reassembled packet\nagainst IP_MAXPACKET.\n\nBut there
    is an integer overflow that can happen a little earlier. We\nare doing:\n\n        i
    = ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) -\n            ntohs(ip->ip_off);\n
    \       [...]\n        ip->ip_off = htons(ntohs(ip->ip_off) + i);\n\nIt is possible
    that\n\n        ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) > 65535\n\nso
    the computation of ip_off wraps to zero. This breaks an assumption in\nthe reassembler
    - it expects the list of fragments to be ordered by\noffset, and here it's not
    ordered anymore. (Un)Fortunately I couldn't\nturn this into anything exploitable.\n\nWith
    the new check, it is guaranteed that ip_off+ip_len<=65535.\n"
  module: src
  subject: 'CVS commit: [netbsd-8] src/sys/netinet'
  unixtime: '1522408214'
  user: martin