dbCaPutLinkCallback can write out of bounds

Interesting, I'm slightly surprised that caget didn't catch that.

Putting up to twice the length of the target is still safe because the circular buffer code makes the pdest pointer wrap around after it reaches the end of the buffer the first time, but after the second time it will overflow.

Should this have been checked/prevented by the dbConvert.c routines? That file changed significantly in 3.15, so I would say don't bother doing it in 3.14 in any case.

Cancel that surprise, your caput is legal.

> Should this have been checked/prevented by the dbConvert.c routines?

This is the question. How do we want dbPutConvertRoutine[][] to behave? Either it does the check, or it doesn't.

I would note that the only other caller of dbPutConvertRoutine[][] in Base now is dbPut(), which does an explicit bounds check before calling.

> That file changed significantly in 3.15, so I would say don't bother doing it in 3.14 in any case.

For 3.14 the easy fix of adding a bounds check in dbCaPutLinkCallback() is IMO worthwhile.

I found this while writing unittests for dbCa while I will be posting soon.

> For 3.14 the easy fix of adding a bounds check in dbCaPutLinkCallback() is IMO worthwhile.

Agreed, please go ahead with that.

BTW one of the tests we should have for dbCa (which will fail so we also have to fix the code) is to have a link pointing to a channel that changes data type and/or array size over a disconnect/reconnect. This is bug#541221, which I was looking at and trying to fix just the other day. I have code that unsubscribes the native data type when a channel reconnects with changed parameters, but so far I have only succeeded in moving the assertion failure to a different spot. I hope to resolve this soon now that I've started on it, but I have other things I have to work on too which might delay the fix.

Of course the opposite case has the opposite problem. Writing 2 elements into 10 leaves 8 uninitialized.

I guess the short term (3.14/3.15) fix is to zero the remaining buffer? For 3.16 should this be changed to only ca_array_put() with the actual number of elements?

> Invalid read of size 4
> at 0x402734: checkArray (dbCaLinkTest.c:300)
> by 0x402ABA: testArrayLink (dbCaLinkTest.c:372)
> by 0x402B3F: main (dbCaLinkTest.c:394)
> Address 0x6e25288 is 0 bytes after a block of size 40 alloc'd
> at 0x4C272B8: calloc (vg_replace_malloc.c:566)
> by 0x539F1F9: callocMustSucceed (cantProceed.c:28)
> by 0x40425F: init_record (arrRecord.c:85)

Fix committed to the 3.14 branch which prevents the buffer overflow when the destination is too small, and zeros uninitialized elements when the destination is too large. The written array size does not change.