[Swan-dev] why I added a consistency check to pbs_in_struct

[Andrew Cagney]

On Sat, 8 May 2021 at 15:33, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | The old behavior was that a NULL implied that the nested struct, if any,
> | could be ignored.  I'd call that obvious behaviour.
> | (passing a pbs when not needed was benign).
>
> That's not what the contract said.  Ever.
>

So let me see
- what matters is the code, and how developers are using it in the wild
vs:
- what matters is the contract, no matter how much this differs from how
the code is being used
Given a choice, I always assume the former is more up-to-date.
Why not just correct the description.

>
> | Now, if this is done wrong, and on a rarely executed code path, we've
> got a
> | ticking time bomb.
>
>
The packet parser code is at the mercy of what the attacker is sending over
the wire.
So we need to be defensive against that, and against our own code.

Minimally, this code shouldn't abort.




> |  Would it have crashed pluto?
>
> I wish.
>
> If I remember correctly (no guarantee -- this was a transient state in
> development a while back), the code got further before it went awry.
> Then we had to backtrack to the cause.
>

It sounds like the caller passed in a pbs_in but it was left uninitialized;
or pointing at NULL.
The former shouldn't have happened - be defensive always scrub the
parameters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210508/5c2f5a18/attachment-0001.html>