On Fri, Aug 24, 2012 at 10:27:29AM -0400, Chuck Rolke wrote:
> This sounds like a gratuitous trailing null. 
> Added nulls could be happening on all buffer sizes but don't cause an issue 
> until the power-of-2-size payload puts the null into territory that gets 
> checked for buffer overruns.

I think you're onto something there. Putting some debugging code into
the wrapper, I'm seeing that at those points the data returns by
pn_message_save is corrupted; i.e., on those specific lengths the
data returns doesn't even remotely match. For example:

[TEST AT 64 CHARACTERS]
Testing data at 64 characters.
Trying with a bufsize of 1024.
rc=0
bufsize=64
*ALLOC_OUTPUT is 65 bytes.
*ALLOC_OUTPUT ==
"vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcgP"
Exiting with a return code of 64
Comparing:
vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
Do they match? Yes

[TEST AT 65 CHARACTERS]
Testing data at 65 characters.
Trying with a bufsize of 1024.
rc=0
bufsize=65
*ALLOC_OUTPUT is 4 bytes.
*ALLOC_OUTPUT == "�j� "
Exiting with a return code of 65
Comparing:
obinopuaxubdehrwmkqqxhitzcfroiqnzdoxjqcqvkgpwsdprryegwxluiheklaul
�j�

pkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg
Do they match? No

As you can, at 64 bytes (and all lengths prior to it) the strings
internal always match. But, at 65 bytes the result is those weird few
characters and nothing even remotely like the string passed in
previously.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

Attachment: pgpNWYCxoENYu.pgp
Description: PGP signature

Reply via email to