Buffer overrun in vector/diglib dig__fread_port_L with big-endian negative values on LP64 systems

[rroliver]

The code in digfread_port_L is broken for handling big endian negative numbers on systems where sizeof(long) != PORT_LONG.

Presently the code fails to negate the value and will write 4 bytes past the end of the buffer.

Problem exists for all grass versions through to trunk...

Patch attached (patch against 6.4.1)

[rroliver]

Patch to fix buffer overrun in digfread_port_L

[mmetz]

Replying to rroliver:

The code in dig__fread_port_L is broken for handling big endian negative numbers on systems where sizeof(long) != PORT_LONG.

Presently the code fails to negate the value and will write 4 bytes past the end of the buffer.

Problem exists for all grass versions through to trunk...

The patch seems to make sense but there are more subtle bugs in lib/diglib/portable.c related to big endian systems. Can you test grass7 (trunk)? I have applied your patch plus some more modifications in trunk in r47992. After testing, they can be backported to 6.5. and 6.4.2.

Markus M

[hamish]

Replying to mmetz in #2085:

It seems that r47992 needs to be backported (see also #1430).

ok, I guess the portable.c part of r56890 wants backporting too?

​https://trac.osgeo.org/grass/changeset/56890/grass/trunk/lib/vector/diglib/portable.c

actually the backport is not so simple since there were a number of other LFS changes to the file in trunk since r32526:

​https://trac.osgeo.org/grass/log/grass/trunk/lib/vector/diglib/portable.c

thanks, Hamish

[mmetz]

Replying to hamish:

Replying to mmetz in #2085:

It seems that r47992 needs to be backported (see also #1430).

ok, I guess the portable.c part of r56890 wants backporting too?

Right, done in r57855,6.

[hamish]

Replying to mmetz:

Replying to hamish:

Replying to mmetz in #2085:

It seems that r47992 needs to be backported (see also #1430).

ok, I guess the portable.c part of r56890 wants backporting too?

Right, done in r57855,6.

a sincere thank you, but please let changes to the core libraries prove themselves in devbr6 for a couple weeks before backporting into relbr64.

thanks, Hamish

[mmetz]

Replying to hamish:

Replying to mmetz:

Replying to hamish:

Replying to mmetz in #2085:

It seems that r47992 needs to be backported (see also #1430).

ok, I guess the portable.c part of r56890 wants backporting too?

Right, done in r57855,6.

a sincere thank you, but please let changes to the core libraries prove themselves in devbr6 for a couple weeks before backporting into relbr64.

Apparently, this bug appeared in the official testing environment of Debian with the officially included GRASS version 6.4.3 on big endian hardware. I guess that it will take 3 - 4 years until my change will be tested in the same testing environment (Debian on big endian hardware with GRASS version 6.4.4, yet to be released and after that to be included into Debian).

We know that GRASS 7 compiles successfully on big endian hardware with AIX as OS. Therefore I am confident that my change will fix the reported bug. It would be preferable if a GRASS developer would have access to big endian hardware with Linux or BSD as OS and would regularly test svn versions of GRASS on such a system.

Further more, I would like to see the development branch of GRASS to be deleted.

[mmetz]

Replying to hamish:

Replying to mmetz:

Replying to hamish:

Replying to mmetz in #2085:

It seems that r47992 needs to be backported (see also #1430).

ok, I guess the portable.c part of r56890 wants backporting too?

Right, done in r57855,6.

a sincere thank you, but please let changes to the core libraries prove themselves in devbr6 for a couple weeks before backporting into relbr64.

The change works in relbr64 with Fedora for ppc64. It seems that devbr6 will not get tested any time soon.

[neteler]

Since nothing appears to be left open here since r57856 addressed relbranch64 2 years ago, closing.