On Wed, Oct 23, 2013 at 7:29 PM, Jeff King <p...@peff.net> wrote:
> On Wed, Oct 23, 2013 at 07:55:06PM +0700, Nguyen Thai Ngoc Duy wrote:
>> The old code does not do boundary check so any paths longer than
>> PATH_MAX can cause buffer overflow. Replace it with strbuf to handle
>> paths of arbitrary length.
> I think this is a reasonable solution. If we have such a long path, we
> are probably about to feed it to open() or another syscall, and we will
> just get ENAMETOOLONG there anyway. But certainly we need to fix the
> buffer overflow, and we are probably better off letting the syscall
> report failure than calling die(), because we generally handle the
> syscall failure more gracefully (e.g., by reporting the failed path but
>> - memcpy(path, state->base_dir, len);
>> - strcpy(path + len, ce->name);
>> - len += ce_namelen(ce);
>> + strbuf_reset(&path_buf);
>> + strbuf_addf(&path_buf, "%.*s%s", state->base_dir_len, state->base_dir,
>> + path = path_buf.buf;
>> + len = path_buf.len;
> This is not something you introduced, but while we are here, you may
> want to use ce->namelen, which would be a little faster than treating it
> as a string (especially for strbuf, as it can then know up front how big
> the size is).
> I doubt it's measurable, though (especially as the growth cost is
> amortized due to the static buffer).
I somehow feel that:
strbuf_add(&path_buf, state->base_dir, state->base_dir_len);
strbuf_add(&path_buf, state->name, state->name_len);
feels a bit neater than using strbuf_addf. But that might just be me.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html