From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cniiU-0005oZ-R7 for qemu-devel@nongnu.org; Tue, 14 Mar 2017 05:26:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cniiQ-0002Nx-HB for qemu-devel@nongnu.org; Tue, 14 Mar 2017 05:26:06 -0400 Date: Tue, 14 Mar 2017 10:25:49 +0100 From: Kevin Wolf Message-ID: <20170314092549.GA3952@noname.str.redhat.com> References: <20170314090922.28083-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170314090922.28083-1-stefanha@redhat.com> Subject: Re: [Qemu-devel] [PATCH] file-posix: clean up max_segments buffer termination List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Fam Zheng Am 14.03.2017 um 10:09 hat Stefan Hajnoczi geschrieben: > The following pattern is unsafe: > > char buf[32]; > ret = read(fd, buf, sizeof(buf)); > ... > buf[ret] = 0; > > If read(2) returns 32 then a byte beyond the end of the buffer is > zeroed. > > In practice this buffer overflow does not occur because the sysfs > max_segments file only contains an unsigned short + '\n'. The string is > always shorter than 32 bytes. > > Regardless, avoid this pattern because static analysis tools might > complain and it could lead to real buffer overflows if copy-pasted > elsewhere in the codebase. > > Signed-off-by: Stefan Hajnoczi Oops. I should have found this during review. Thanks for catching it. Thanks, applied to the block branch. Kevin