Re: Buffer overflow in extract_diag_error_w()

Hi,

I tested 2.3.4 and it does not segfault. The netezza driver is a bit 
buggy, so I wouldn't be surprised if it is doing something wrong.

Thanks for your help.

-Andrew

On 11/11/15 23:00, [email protected] wrote:
> Send unixODBC-dev mailing list submissions to
> 	[email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
>
> You can reach the person managing the list at
> 	[email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of unixODBC-dev digest..."
>
>
> Today's Topics:
>
>     1. Buffer overflow in extract_diag_error_w() (Andrew Punch)
>     2. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>     3. Re: Buffer overflow in extract_diag_error_w() (Andrew Punch)
>     4. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>     5. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Nov 2015 17:32:03 +1100
> From: Andrew Punch <[email protected]>
> Subject: [unixODBC-dev] Buffer overflow in extract_diag_error_w()
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I am working with Netezza in Perl. The script was crashing with a
> segfault. When I used gdb to investigate the problem was isolated to the
> wide_strcpy() call in extract_diag_error_w() due to a larger than
> expected error message from the Netezza driver. The error message from
> the Netezza driver was not corrupt and was in the correct format.
>
> I solved this problem in the short term by increasing
> SQL_MAX_MESSAGE_LENGTH from 512 to 1024. Ideally something like
> wcscpy_s() should be used.
>
> Thanks
> -Andrew
>
> diff -ur unixODBC-2.3.1/include/sql.h unixodbc-2.3.1-patched/include/sql.h
> --- unixODBC-2.3.1/include/sql.h    2011-07-04 18:54:09.000000000 +1000
> +++ unixodbc-2.3.1-patched/include/sql.h    2015-11-11
> 16:13:26.709201111 +1100
> @@ -46,7 +46,7 @@
>    #define SQL_NTSL                  (-3L)
>
>    /* maximum message length */
> -#define SQL_MAX_MESSAGE_LENGTH   512
> +#define SQL_MAX_MESSAGE_LENGTH   1024
>
>    /* date/time length constants */
>    #if (ODBCVER >= 0x0300)
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Nov 2015 09:50:42 +0000
> From: Nick Gorham <[email protected]>
> Subject: Re: [unixODBC-dev] Buffer overflow in extract_diag_error_w()
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 11/11/15 06:32, Andrew Punch wrote:
>> Hi,
>>
>> I am working with Netezza in Perl. The script was crashing with a
>> segfault. When I used gdb to investigate the problem was isolated to
>> the wide_strcpy() call in extract_diag_error_w() due to a larger than
>> expected error message from the Netezza driver. The error message from
>> the Netezza driver was not corrupt and was in the correct format.
>>
>> I solved this problem in the short term by increasing
>> SQL_MAX_MESSAGE_LENGTH from 512 to 1024. Ideally something like
>> wcscpy_s() should be used.
>>
>> Thanks
>> -Andrew
>>
>> diff -ur unixODBC-2.3.1/include/sql.h
>> unixodbc-2.3.1-patched/include/sql.h
>> --- unixODBC-2.3.1/include/sql.h    2011-07-04 18:54:09.000000000 +1000
>> +++ unixodbc-2.3.1-patched/include/sql.h    2015-11-11
>> 16:13:26.709201111 +1100
>> @@ -46,7 +46,7 @@
>>   #define SQL_NTSL                  (-3L)
>>
>>   /* maximum message length */
>> -#define SQL_MAX_MESSAGE_LENGTH   512
>> +#define SQL_MAX_MESSAGE_LENGTH   1024
>>
>>   /* date/time length constants */
>>   #if (ODBCVER >= 0x0300)
>> _______________________________________________
>> unixODBC-dev mailing list
>> [email protected]
>> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
> Hi, SQL_MAX_MESSAGE_LENGTH is defined by the MS headers so we don't want
> to alter that, but have you tried a current build of unixODBC, as 2.3.1
> was from 26th November 2011. I think the problem is fixed in 2.3.3, the
> changes contain "Fix buffer overrun returning long diagnostic from driver".
>
> Try the current, 2.3.5-pre and if the problem is still there, provide
> details and we will sort it out. How long is the message that comes from
> the driver?
>

_______________________________________________
unixODBC-dev mailing list
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev