--- - 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