Dangling pointer in SimpleKeyingInterface::GetIVAndThrowIfInvalid

[Mark Millard]

For Crypto++ V5.6.0 in...

const byte * SimpleKeyingInterface::GetIVAndThrowIfInvalid(const
NameValuePairs &params, size_t &size)
{
ConstByteArrayParameter ivWithLength;
const byte *iv;
bool found = false;

try {found = params.GetValue(Name::IV(), ivWithLength);}
catch (const NameValuePairs::ValueTypeMismatch &) {}

if (found)
{
iv = ivWithLength.begin();
ThrowIfInvalidIV(iv);
size = ThrowIfInvalidIVLength((int)ivWithLength.size());
return iv;

when ivWithLength ends up with a SecDlock from a deep copy, the
ivWithLength destruction at the return means that the iv pointer is
dangling to unowned memory after the return. This was noticed from the
initialization vector value being wrong under a debugger and watching
the pointer to value change during the destruction.

[Wei Dai]

You're right, that code causes a dangling pointer if you pass it an IV using
ConstByteArrayParameter with deepCopy = true, which I hadn't considered that
someone might do. I can add a check for that and throw an error if deepCopy
= true, or do you need that to be supported for some reason?

--------------------------------------------------
From: "Mark Millard" <mar...@dsl-only.net>
Sent: Thursday, November 05, 2009 10:16 AM
To: "Crypto++ Users" <cryptop...@googlegroups.com>
Subject: Dangling pointer in SimpleKeyingInterface::GetIVAndThrowIfInvalid

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the "Crypto++
> Users" Google Group.
> To unsubscribe, send an email to
> cryptopp-user...@googlegroups.com.
> More information about Crypto++ and this group is available at
> http://www.cryptopp.com.
> -~----------~----~----~----~------~----~------~--~---
>
>

[Mark Millard]

Hi.

I just quit using deep copy for what I was fiddling with and control
the life-time of what is now pointed to.

I've no code with dependence on deep copy now.


===
Mark Millard
mar...@dsl-only.net