From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ravik Hasija Date: Tue, 2 Jun 2020 19:54:46 -0700 (MST) Subject: [PATCH v4] net: tftp: Add client support for RFC 7440 In-Reply-To: <20200519192557.18075-1-rfried.dev@gmail.com> References: <20200519192557.18075-1-rfried.dev@gmail.com> Message-ID: <1591152886830-0.post@n7.nabble.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Ramon Fried-4 wrote > + if (strcmp((char *)pkt + i, "windowsize") == 0) { > For servers that doesnt support windowsize option the above check could > result in accessing memory outside of valid range. Please check if (i+11) > < len before comparing the strings. > > > + > + if (ntohs(*(__be16 *)pkt) != (ushort)(tftp_cur_block + 1)) { > + debug("Received unexpected block: %d, expected: %d\n", > + ntohs(*(__be16 *)pkt), > + (ushort)(tftp_cur_block + 1)); > + /* > + * If one packet is dropped most likely > + * all other buffers in the window > + * that will arrive will cause a sending NACK. > + * This just overwellms the server, let's just send one. > + */ > + if (tftp_last_nack != tftp_cur_block) { > + tftp_send(); > + tftp_last_nack = tftp_cur_block; > + tftp_next_ack = (ushort)(tftp_cur_block + > + tftp_windowsize); > + } > + break; > + } > + > + tftp_cur_block++; > > Monotonically increasing the tftp_cur_block will cause error for cases > where sequence number wraps around as tftp_cur_block is ulong, thus during > wraparound the check ntohs(*(__be16 *)pkt) != (ushort)(tftp_cur_block + 1) > will fail and incorrectly generate ACK, and the connection will eventually > be terminated once the retry is exhausted. Please modulo the increment > with TFTP_SEQUENCE_SIZE. > -- > 2.26.2 Quoted from: http://u-boot.10912.n7.nabble.com/PATCH-v4-net-tftp-Add-client-support-for-RFC-7440-tp412754.html -- Sent from: http://u-boot.10912.n7.nabble.com/