[CONC-63] Memory corruption in my_net_read of net.c n Windows 64 bit Created: 2013-12-26  Updated: 2014-01-11  Resolved: 2014-01-11

Status: Closed
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dror Harari Assignee: Georg Richter
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Windows 64bit build, mariadb-native-client.tar.gz of 2012-11-29


 Description   

In net.c line 656 in the call to my_real_read, a pointer to complen which is ulong (32-bit bit in MSVC 64-bit builds) is passed as the third argument which expects a pointer to size_t (64-bit in MSVC 64-bit builds). As a result, 4 bytes of some other use are overwritten.

The buggy code is hidden away by a (size_t *) cast:

>>>> Start
ulong my_net_read(NET *net)
{
ulong len,complen;

#ifdef HAVE_COMPRESS
if (!net->compress)
{
#endif
len = my_real_read (net,(size_t *)&complen);
^--- Bug
>>>> End

A possible fix is as follows:

>>>> Start
ulong my_net_read(NET *net)
{
ulong len,complen;
size_t complen_tmp;

#ifdef HAVE_COMPRESS
if (!net->compress)
{
#endif
len = my_real_read (net,&complen_tmp);
complen = complen_tmp;
>>>> End

 Comments   
Comment by Georg Richter [ 2013-12-30 ]

Can you please try to reproduce with latest revision (107) from launchpad.net (bzr branch lp:mariadb-native-client)

Comment by Dror Harari [ 2013-12-31 ]

Could not reproduce. Just to be clear - the memory corruption exception was not observable with the release build, only with the debug build. The reason was that the debug build places guards around local variables and that bug corrupted the guard value. The new code does not use ulong so it should not trigger that bug (though it is not clear to me why the (size_t *) cast was left in the my_real_read() function call:

ulong my_net_read(NET *net)
{
size_t len,complen;

#ifdef HAVE_COMPRESS
if (!net->compress)
{
#endif
len = my_real_read (net,(size_t *)&complen);
if (len == MAX_PACKET_LENGTH)
{....

From my perspective, the bug was fixed. Thanks.

Dror

Comment by Georg Richter [ 2014-01-11 ]

Bug was already fixed

Generated at Thu Feb 08 03:02:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.