[devel] Опять переполнение буфера (memcpy)
Sergey Vlasov
vsu at altlinux.ru
Fri Nov 13 10:29:24 UTC 2009
On Fri, Nov 13, 2009 at 11:34:54AM +0300, Damir Shayhutdinov wrote:
> >>> https://bugzilla.altlinux.org/show_bug.cgi?id=22276
> >>
> >> Лучше б ссылку на git дали, чтоб хоть исходники можно было посмотреть.
> >
> > http://tinyurl.com/yzmh82g
> Ок, тогда все понятно.
>
> 334 char spb[6];
> 335 char *spb_walk = spb;
>
> Размер буфера - 6 байт.
> Этого не хватает, чтобы вместить unsigned long на x86_64 (8 байт),
> который туда суется через memcpy.
>
> Для решения можно исправить в строке 334 число 6 на число 10.
Это не решение, а затычка для получения кода, который собирается, но
не работает.
Реализация ADD_SPB_NUMERIC в ibase.h выглядит так:
#define ADD_SPB_NUMERIC(p, data) {*(p)++ = (ISC_SCHAR) (data); \
*(p)++ = (ISC_SCHAR) ((data) >> 8); \
*(p)++ = (ISC_SCHAR) ((data) >> 16); \
*(p)++ = (ISC_SCHAR) ((data) >> 24);}
"Замена" этого макроса в kinterbasdb делает кое-что совсем другое:
#define ADD_SPB_NUMERIC_DSR(buf_pos, data) \
memcpy(buf_pos, &data, sizeof(unsigned long)); \
buf_pos += sizeof(unsigned long);
Т.е., вместо 32-разрядного числа (причём всегда little endian
независимо от платформы) в буфер попадёт число неизвестной разрядности
и с неизвестным порядком байтов. Увеличение размера буфера просто
маскирует эту проблему.
На самом деле нужно просто заменить кривой макрос ADD_SPB_NUMERIC_DSR
на ADD_SPB_NUMERIC (возможно, обложив его дополнительными приведениями
типов, если вылезут лишние предупреждения).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091113/810b7a48/attachment.bin>
More information about the Devel
mailing list