On 10/24/14 15:49, Michael Tokarev wrote:
> 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 <gang.chen.5i5j@xxxxxxxxx>
>>
>> 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.
>
> (Or alternatively there's asprintf(), but still I think it is overkill).
>
> I can apply the above if everyone agrees.
>
For me, what you said is reasonable, although I am not sure whether the
patch v2 for g_strdup_printf() was already applied or not.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
