Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2026-04

possible unicode buffer overflow

9 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Weustink

Hi,

In order to track unfreed memory at work, I've written a custom memory manager wrapper around the default manager.
To be sure that the memory isn't corrupted, the returned memory blocks are surrounded by guard bytes.

What I see when a string is released that there is no room for the trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so I assume the extra null is somewhere written when creating the string

Running fpc 3.2.2 win 64

allocated size: 36 bytes
guard start: CC BB BB BB BB BB BB CC
guard end: CC FF FF FF FF FF FF CC

CC BB BB BB BB BB BB CC B0 04 02 00 0D F0 AD BA ................ 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 ................ 6E 00 6F 00 62 00 65 00 61 00 74 00 00 00 FF FF n.o.b.e.a.t..... FF FF FF CC ....

What you see here is that the first 2 bytes of the end guard are overwritten.

Is this issue known ?

Thanks, Marc

Reply by email

Michael Van Canneyt
to Marc Weustink
Marc Weustink wrote 10 lines
Hi, In order to track unfreed memory at work, I've written a custom memory manager wrapper around the default manager. To be sure that the memory isn't corrupted, the returned memory blocks are surrounded by guard bytes. What I see when a string is released that there is no room for the trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so I assume the extra null is somewhere written when creating the string

Unicode strings are supposed to be 00 terminated, AFAIK.

Show quoted text 15 lines
Running fpc 3.2.2 win 64 allocated size: 36 bytes guard start: CC BB BB BB BB BB BB CC guard end: CC FF FF FF FF FF FF CC CC BB BB BB BB BB BB CC B0 04 02 00 0D F0 AD BA ................ 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00 ................ 6E 00 6F 00 62 00 65 00 61 00 74 00 00 00 FF FF n.o.b.e.a.t..... FF FF FF CC .... What you see here is that the first 2 bytes of the end guard are overwritten. Is this issue known ?

Is the behaviour also there in 3.3.1 ?

Michael.

Reply by email

Marc Weustink
to Michael Van Canneyt
Michael Van Canneyt wrote 35 lines
On Fri, 17 Apr 2026, Marc Weustink via fpc-devel wrote: > Hi, > > In order to track unfreed memory at work, I've written a custom memory > manager wrapper around the default manager. > To be sure that the memory isn't corrupted, the returned memory blocks > are surrounded by guard bytes. > > What I see when a string is released that there is no room for the > trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so I > assume the extra null is somewhere written when creating the string Unicode strings are supposed to be 00 terminated, AFAIK. > > Running fpc 3.2.2 win 64 > > allocated size: 36 bytes > guard start: CC BB BB BB BB BB BB CC > guard end:   CC FF FF FF FF FF FF CC > >  CC BB BB BB BB BB BB CC  B0 04 02 00 0D F0 AD BA  ................ >  00 00 00 00 00 00 00 00  06 00 00 00 00 00 00 00  ................ >  6E 00 6F 00 62 00 65 00  61 00 74 00 00 00 FF FF  n.o.b.e.a.t..... >  FF FF FF CC                                       .... > > What you see here is that the first 2 bytes of the end guard are > overwritten. > > Is this issue known ? Is the behaviour also there in 3.3.1 ?

Somehow I expected this response ;) I'll see if I can use 3.3.1

Marc

Reply by email

Marc Weustink
to Marc Weustink

Sorry, I can't get lazarus to compile using a 3.3.1 compiler. I'll sort this out later (if ever, work calls)

Marc

Marc Weustink wrote 46 lines
On 17/04/2026 14:15, Michael Van Canneyt via fpc-devel wrote: > > > On Fri, 17 Apr 2026, Marc Weustink via fpc-devel wrote: > >> Hi, >> >> In order to track unfreed memory at work, I've written a custom >> memory manager wrapper around the default manager. >> To be sure that the memory isn't corrupted, the returned memory >> blocks are surrounded by guard bytes. >> >> What I see when a string is released that there is no room for the >> trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so I >> assume the extra null is somewhere written when creating the string > > Unicode strings are supposed to be 00 terminated, AFAIK. > >> >> Running fpc 3.2.2 win 64 >> >> allocated size: 36 bytes >> guard start: CC BB BB BB BB BB BB CC >> guard end:   CC FF FF FF FF FF FF CC >> >>  CC BB BB BB BB BB BB CC  B0 04 02 00 0D F0 AD BA  ................ >>  00 00 00 00 00 00 00 00  06 00 00 00 00 00 00 00  ................ >>  6E 00 6F 00 62 00 65 00  61 00 74 00 00 00 FF FF  n.o.b.e.a.t..... >>  FF FF FF CC                                       .... >> >> What you see here is that the first 2 bytes of the end guard are >> overwritten. >> >> Is this issue known ? > > Is the behaviour also there in 3.3.1 ? Somehow I expected this response ;) I'll see if I can use 3.3.1 Marc _______________________________________________ fpc-devel maillist  -  https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Marc Weustink
to Marc Weustink

I can't believe it, but ansistrings, resource loading, string formatting, all are affected and writing one, two or even more bytes behind the buffer.

Marc

Marc Weustink wrote 57 lines
Sorry, I can't get lazarus to compile using a 3.3.1 compiler. I'll sort this out later (if ever, work calls) Marc On 17/04/2026 14:26, Marc Weustink via fpc-devel wrote: > > > On 17/04/2026 14:15, Michael Van Canneyt via fpc-devel wrote: >> >> >> On Fri, 17 Apr 2026, Marc Weustink via fpc-devel wrote: >> >>> Hi, >>> >>> In order to track unfreed memory at work, I've written a custom >>> memory manager wrapper around the default manager. >>> To be sure that the memory isn't corrupted, the returned memory >>> blocks are surrounded by guard bytes. >>> >>> What I see when a string is released that there is no room for the >>> trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so >>> I assume the extra null is somewhere written when creating the string >> >> Unicode strings are supposed to be 00 terminated, AFAIK. >> >>> >>> Running fpc 3.2.2 win 64 >>> >>> allocated size: 36 bytes >>> guard start: CC BB BB BB BB BB BB CC >>> guard end:   CC FF FF FF FF FF FF CC >>> >>>  CC BB BB BB BB BB BB CC  B0 04 02 00 0D F0 AD BA  ................ >>>  00 00 00 00 00 00 00 00  06 00 00 00 00 00 00 00  ................ >>>  6E 00 6F 00 62 00 65 00  61 00 74 00 00 00 FF FF  n.o.b.e.a.t..... >>>  FF FF FF CC                                       .... >>> >>> What you see here is that the first 2 bytes of the end guard are >>> overwritten. >>> >>> Is this issue known ? >> >> Is the behaviour also there in 3.3.1 ? > > Somehow I expected this response ;) I'll see if I can use 3.3.1 > > Marc > > _______________________________________________ > fpc-devel maillist  -  > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel _______________________________________________ fpc-devel maillist  -  https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Michael Van Canneyt
to Marc Weustink
Marc Weustink wrote
I can't believe it, but ansistrings, resource loading, string formatting, all are affected and writing one, two or even more bytes behind the buffer.

That sounds strange, we'd have much more error reports if this was the case...

Michael.

Reply by email

Marc Weustink
to Michael Van Canneyt
Michael Van Canneyt wrote 10 lines
On Fri, 17 Apr 2026, Marc Weustink via fpc-devel wrote: > I can't believe it, but ansistrings, resource loading, string > formatting, all are affected and writing one, two or even more bytes > behind the buffer. That sounds strange, we'd have much more error reports if this was the case...

That's why I can't believe it. However, since all mem is allocated in multiple of 32 bytes, you only run into it when allocating exactly a multiple of that.

Anyway, I need to finish my piece of software before the end of this month, so I've little time to dive deeper into this.

(For the product it isn't a problem, while I'm coding using FPC+Laz, the final product is build in Delphi)

Marc

Reply by email

Marc Weustink
to Marc Weustink

Ignore it. My error.

Marc

Marc Weustink wrote 29 lines
On 17/04/2026 16:40, Michael Van Canneyt via fpc-devel wrote: > > > On Fri, 17 Apr 2026, Marc Weustink via fpc-devel wrote: > >> I can't believe it, but ansistrings, resource loading, string >> formatting, all are affected and writing one, two or even more bytes >> behind the buffer. > > That sounds strange, we'd have much more error reports if this was the > case... That's why I can't believe it. However, since all mem is allocated in multiple of 32 bytes, you only run into it when allocating exactly a multiple of that. Anyway, I need to finish my piece of software before the end of this month, so I've little time to dive deeper into this. (For the product it isn't a problem, while I'm coding using FPC+Laz, the final product is build in Delphi) Marc _______________________________________________ fpc-devel maillist  -  https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Marco van de Voort
to Michael Van Canneyt: Unicode strings are supposed to be 00 terminated, AFAIK. Is the behaviour also there in…

Op 17-4-2026 om 14:15 schreef Michael Van Canneyt via fpc-devel:

Show quoted text 12 lines
> > > In order to track unfreed memory at work, I've written a custom > memory manager wrapper around the default manager. > To be sure that the memory isn't corrupted, the returned memory > blocks are surrounded by guard bytes. > > What I see when a string is released that there is no room for the > trailing null. The free is triggered by FPC_UNICODESTR_DECR_REF, so I > assume the extra null is somewhere written when creating the string Unicode strings are supposed to be 00 terminated, AFAIK.

Marc has already resolved it, but afaik the 3.3.1 heapmanager has more (fastmm like) options? Do you know if there is a description of that somewhere?

Reply by email