From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [Qemu-trivial] [PATCH] target-ppc: kvm: Fix memory overflow issue about strncat() Date: Fri, 24 Oct 2014 10:05:12 +0200 Message-ID: <2DF5C850-3F54-4592-AFE6-C5AC16033F06@suse.de> References: <543BE352.3080609@gmail.com> <543BE616.1000707@suse.de> <544A046D.4090204@msgid.tls.msk.ru> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: Chen Gang , "pbonzini@redhat.com" , "qemu-trivial@nongnu.org" , "qemu-ppc@nongnu.org" , qemu-devel , "kvm@vger.kernel.org" To: Michael Tokarev Return-path: Received: from cantor2.suse.de ([195.135.220.15]:45172 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751445AbaJXIFP convert rfc822-to-8bit (ORCPT ); Fri, 24 Oct 2014 04:05:15 -0400 In-Reply-To: <544A046D.4090204@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: > Am 24.10.2014 um 09:49 schrieb Michael Tokarev : > >> On 10/13/2014 06:47 PM, Alexander Graf wrote: >>> On 13.10.14 16:36, Chen Gang wrote: >>> strncat() will append additional '\0' to destination buffer, so need >>> additional 1 byte for it, or may cause memory overflow, just like other >>> area within QEMU have done. >>> >>> Signed-off-by: Chen Gang >> >> I agree with this patch. However, the code is pretty ugly - I'm sure it >> must've been me who wrote it :). >> >> Could you please instead rewrite it to use g_strdup_printf() rather than >> strncat()s? That way we resolve all string pitfalls automatically - and >> this code is not the fast path, so doing an extra memory allocation is ok. > > I'd just use snprintf() like this: > > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 9c23c6b..5eaa36c 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -1794,8 +1794,7 @@ static uint64_t kvmppc_read_int_cpu_dt(const char *propname) > return -1; > } > > - strncat(buf, "/", sizeof(buf) - strlen(buf)); > - strncat(buf, propname, sizeof(buf) - strlen(buf)); > + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), "/%s", propname); > > f = fopen(buf, "rb"); > if (!f) { > > the buffer is of size PATH_MAX, and we're looking at /proc filesystem where > names should be rather short so we're extremly unlikely to hit this prob in > practice, there's no need to dynamically allocate a buffer for this stuff. I've already applied the fix to ppc-next. > > (Or alternatively there's asprintf(), but still I think it is overkill). That one isn't portable iirc. > > I can apply the above if everyone agrees. No worries, it's all over already ;). Alex